Khamidullo Maratov

Platform Engineer · DanaCloud · Seoul

KhamidulloMaratov

I build cloud backends and developer tools that fail safe. Five wrong passwords lock an account, and deleting a server means typing its name first.

View projects Get in touch
Now
Backend and CLI work on DanaIX, an OpenStack public cloud
Focus
Auth, provisioning, developer tooling
Background
BEng Information Security, two research roles
Speaks
Uzbek, Russian, English, Korean
three_body / figure_eightvelocity Verlet · fixed dt
E −1.28714 t 0.00 The figure-eight three-body orbit, running in your browser with velocity Verlet, the integrator EMMA uses. The total energy E stays level. With plain Euler steps it would drift until the orbit flew apart.

about.md

About

I'm a platform engineer at DanaCloud, where I work on DanaIX, an OpenStack-based public cloud. Most of my time goes into the backend services behind the console (authentication, notifications, and IaaS and PaaS provisioning) and into dana, the platform's command-line tool. I'm also building the DanaIX Documentation Center, and I check each page against the service code before it's published.

My degree is in Information Security Engineering, and both of my research roles were security work: anonymizing witnesses in video, and securing drone links, where I built the drones, mapped their control protocol byte by byte and worked on quantum key distribution. I look for the failure case first: anything destructive gets a dry run, and I write down every place my code departs from the spec.

Based in
Seoul, KST (UTC+9)
Current project
ai-study: learning AI by building, from linear algebra visualizations to deep learning with spiking neural networks (snnTorch)
Education
BEng Information Security Engineering, Soonchunhyang University, GPA 3.58 / 4.0
Off hours
Gravity simulations in C++ and quantum randomness on the web

skills.toml

Skills

[languages]

Python every day; C++ and C for systems code and simulation.

  • Python
  • C++
  • C
  • SQL
  • Shell
  • JavaScript
  • Swift

[backend]

The services behind DanaIX: auth, notifications, provisioning.

  • FastAPI
  • PostgreSQL
  • MySQL
  • Redis
  • pytest
  • CLI tooling
  • Git

[cloud]

OpenStack at work, and Docusaurus for the DanaIX documentation center.

  • OpenStack
  • AWS (IAM, EC2, S3)
  • Linux
  • Windows Server
  • Docusaurus

[security]

My degree, applied to auth, APIs and drone links.

  • Linux hardening
  • API security
  • Secrets handling
  • Account lockout
  • Security analysis
  • Wireshark
  • Protocol reverse engineering

[networking]

What a public cloud runs on, from VLANs to floating IPs.

  • TCP/IP
  • Routing & switching
  • DNS
  • VLANs
  • VPCs
  • Floating IPs
  • NAT & gateways
  • DHCP
  • SSH

[quantum_crypto]

QKD for drone links at the consortium, and quantum randomness in Universe Splitter.

  • Qiskit
  • Q#
  • QKD
  • Quantum randomness
  • Cryptography
  • SHA-256
  • Entropy analysis

[hardware]

Raspberry Pi and Arduino in the photo booth, and a drone I built and flew.

  • Raspberry Pi
  • Arduino
  • Drone assembly
  • USB serial
  • Wi-Fi AP / STA
  • ToF sensors
  • Scratch

[research_ml]

Computer vision for witnesses and drones, plus an ongoing study plan.

  • OpenCV
  • MediaPipe
  • Face & gesture recognition
  • Wake-word detection
  • AUC-ROC evaluation
  • Roboflow
  • snnTorch

projects/

Selected projects

One from DanaCloud, two from research, two built on my own time.

$ dana server create web-01 --wait --ssh
✓ input valid
  creating web-01
  waiting for ACTIVE .......... done
  connecting to 203.0.113.24
debian@web-01:~$ exit

$ dana server delete web-01
  This permanently deletes web-01.
  Type the server name to confirm: web-01
✓ deleted web-01
Illustrative session

DanaCloud · developer tooling · 2026

The dana CLI, past its v1.0 spec

Made the dana CLI fast for the common path and careful with destructive commands.

I added server wait and server ssh, chained as create --wait --ssh, plus name-based targeting, a typed confirmation for delete, --dry-run, and input validation before any request goes out.

9additions past the v1.0 spec

1command from create to an SSH session

0requests sent on invalid input

Read moreShow less
Problem
The v1.0 spec covered the API calls and little else. Getting from "create" to a shell meant polling for status and looking up an address, every command needed a server ID, and nothing double-checked a delete.
Approach
I added server wait and server ssh and chained them as create --wait --ssh. Commands accept server names, delete asks you to type the name, --dry-run prints the exact API payload, and the CLI validates input before it sends anything. server create and flavor list show a monthly cost estimate from the per-datacenter pricing catalog, and billing usage ranks resources by spend. I wrote up each deviation from the PRD in an engineering addendum.
Outcome
The common path is one command, and the dangerous ones ask first.
  • Python
  • Typer
  • REST API
  • OpenStack

Internal tool · code private

National Consortium for Drone Security · 2025–26

AIDrone: reading a drone's control link byte by byte

Built and flew a research drone, then decoded the frames it sends and receives.

I traced the drone's SDK down to raw bytes to map its 20-byte command and telemetry frames, then analyzed its Wi-Fi video traffic in Wireshark.

20bytes in every frame, header to checksum

2links analyzed: serial control and Wi-Fi video

3AI features on board: face, gesture, voice

Read moreShow less
Problem
To secure a drone's control link you first need to know exactly what travels over it, down to the byte, and the SDK only exposes it as function calls.
Approach
I assembled the drone, set up Raspberry Pi OS with the Pi as a Wi-Fi access point, and wrote Python keyboard control on the pyaidrone SDK for takeoff, landing, movement, altitude and yaw, plus Scratch automation. To see the control link, I traced the SDK's packet builder and stream parser down to raw bytes. Commands go over USB serial to the radio dongle as fixed 20-byte frames, streamed continuously. The parser is a small state machine: it hunts for a 4-byte header, collects the frame and checks its checksum. For the Wi-Fi link, I captured traffic in Wireshark during live camera streaming and found the MJPEG video stream over TCP. Its spurious retransmissions came from delayed ACKs and showed where the link's latency limits were. Face and gesture recognition, automated photo capture and on-device wake-word voice control came after.
Outcome
A field-by-field map of the command and telemetry frames, and a drone that flies from Python, Scratch or voice commands, with face and gesture recognition on board.
  • Python
  • pyaidrone
  • Raspberry Pi
  • USB serial
  • Wireshark
  • OpenCV

Consortium research

Soonchunhyang University lab · 2024

Witness face anonymization

Makes a witness in video look like a different person, reversibly, without storing their face.

Instead of blurring, it replaces parts of the face and changes hair and eye color, and whoever holds the key can reverse it. I spent about two months evaluating it frame by frame.

0original faces stored

1 frameis a failure, so I checked recall per frame

Read moreShow less
Problem
Video used in legal and security settings has to hide witnesses, and one clear frame is enough to recognize someone.
Approach
Instead of blurring, the system replaces parts of the face and changes features like hair and eye color. The system never stores the original face, and whoever holds the key can run the transformation backwards. I spent about two months on evaluation: running the pipeline over test footage, checking frame by frame for missed faces and glitched swaps, and scoring detection with AUC-ROC across thresholds on imbalanced data.
Outcome
I judged misses per frame and spent the most time on the rare hard cases: faces in profile, partly covered, or badly lit.
  • Python
  • OpenCV
  • MediaPipe
  • PyQt5
  • AUC-ROC

Lab project · code not publicRead the note

EMMA running the solar system: the Sun and the inner planets, labeled, against a field of stars

Personal · open source · C++

EMMA, a real-time gravity simulator

Runs the solar system forward from today's real planet positions, in real units, so Earth takes a year to go around the Sun.

Velocity Verlet keeps the energy error from building up. Close passes split into smaller steps, and above 64 bodies a Barnes-Hut quadtree cuts the force step to about N log N.

10bodies placed from NASA JPL Horizons data for today

27.3days for the Moon to go around Earth

4,096pieces a step can split into during a close pass

Read moreShow less
Problem
Simple N-body demos step with Euler, so the energy error builds up and planets slowly spiral away. One long step through a near miss also jumps past the closest point and sends the two bodies apart faster than they arrived. Summing the pull between every pair gets slow as the body count grows.
Approach
EMMA works in astronomical units, solar masses and days. On start it asks NASA JPL's Horizons service where the Sun, the planets and the Moon are at 00:00 UTC today, and caches the answer so later starts that day need no network. It integrates with velocity Verlet, whose energy error swings around a fixed value. Before each piece of a step it works out every pair's dynamical time and the time the pair needs to close the gap, so a close pass splits into as many as 4,096 pieces. Up to 64 bodies it sums every pair exactly, and above that a Barnes-Hut quadtree treats distant groups as single masses. Merges keep mass and momentum. In the app you click to place a body or drag to launch one, and a dashed line shows its path before you let go.
Outcome
Earth's orbit takes one sidereal year, and energy and angular momentum stay conserved over ten simulated years. The test suite checks both.
  • C++17
  • SFML 3
  • Dear ImGui
  • CMake
  • JPL Horizons API

Code on GitHub

Personal · open source · web

Universe Splitter

A Many-Worlds decision maker that picks between two weighted options using quantum randomness.

It queries seven randomness sources at once through a Cloudflare proxy and hashes every answer with SHA-256 into one draw.

7sources queried per draw

4of them quantum

1honest source is enough

Read moreShow less
Problem
The app's premise needs a draw from physical quantum sources, and any single public source can be offline or untrustworthy.
Approach
The app queries all sources at once through a same-origin Cloudflare proxy, which keeps API keys on the server and spares the browser any cross-origin calls. It hashes the responses together with SHA-256. If nothing answers, it falls back to crypto.getRandomValues and labels the result "not quantum".
Outcome
The draw stays unpredictable as long as any one source is honest. Nothing the user types leaves the browser.
  • React 19
  • Vite
  • Tailwind CSS
  • Cloudflare Pages
  • SHA-256

Code on GitHub

experience.log

Experience

  1. 04/2026 – nowSeoulcurrent

    Platform Engineer

    DanaCloud

    • Work on the backend services behind DanaIX: authentication, notifications, and IaaS and PaaS provisioning (FastAPI, PostgreSQL, Redis).
    • Built account lockout in the authentication service: five consecutive failed sign-ins lock the account for 15 minutes and email a reset link.
    • Extended the dana CLI past its v1.0 spec, with cost estimates and spend ranking from the pricing catalog, and documented every deviation from the PRD.
    • Building the DanaIX Documentation Center on Docusaurus. I revised its PRD from start to finish and made the final calls on it, and I check each page against the service code before it goes live.

  2. 10/2025 – 03/2026Asan

    Researcher

    National Consortium for Drone Security

    • Implemented quantum key distribution to secure drone-to-drone and drone-to-ground-station links for UAV fleets.
    • Designed Qiskit experiments measuring how reliably qubit states survive the QKD process.
    • Built and flew the AIDrone research platform: assembled the hardware, set up the Raspberry Pi as a Wi-Fi access point, and wrote Python keyboard control and Scratch automation.
    • Mapped the drone's 20-byte serial command and telemetry frames from the pyaidrone SDK, and analyzed its Wi-Fi traffic in Wireshark.
    • Added face and gesture recognition with OpenCV, automated photo capture, and on-device wake-word voice control.
    • Developed a hands-on drone workshop that gave students their first flight.

  3. 08/2024 – 12/2024Asan

    AI Software Developer

    Soonchunhyang University

    • Built a face anonymization system in Python and OpenCV to protect witness identities in legal and security settings.
    • Evaluated detection models with AUC-ROC across thresholds on imbalanced datasets.

  4. 06/2024 – 09/2024Cebu, Philippines

    AI Research and Algorithm Development Intern

    University of San Carlos

    • Tuned facial and gesture recognition algorithms in Python and OpenCV through structured experiments.
    • Wired Raspberry Pi and Arduino hardware to control the camera and movement of an interactive photo booth that is still in use.

  5. 09/2021 – 08/2025Asan

    BEng, Information Security Engineering

    Soonchunhyang University · GPA 3.58 / 4.0

    • Coursework in networking, operating systems, computer architecture and cybersecurity.
    • Projects: security analysis of Linux-based EV infotainment systems; deepfake-based avatar spoofing prevention.

notes/

Notes and research

Note · face anonymization project

Why I checked every frame

The part of the face anonymization project I didn't enjoy was evaluation.

At Soonchunhyang University's lab, we built a program to hide witnesses' identities in video. Instead of blurring, it replaces parts of the face and changes features like hair and eye color, so the witness looks like a completely different person. The program never stores the original face, and whoever holds the key can run the transformation backwards. I was a developer on it, using OpenCV, MediaPipe and PyQt5.

But for a bit more than two months, most of my time went into running the pipeline over test footage, checking frame by frame where a face was missed or the swap glitched, and checking that the restored face matched the original. And the cases that mattered most, faces turned to the side, partly covered, or badly lit, were rare in our data.

I kept at it because of what a miss costs. If the system loses a witness's face for even a few frames, their identity is exposed.

One clear frame is enough to recognize someone.

Our data was imbalanced, so a model could score very well and still miss exactly those frames. Only the frame-by-frame checking caught that.

I still prefer building to measuring. But I stopped treating evaluation as the boring part, because it's the only part that tells you whether the thing is safe to ship.