Reverse-engineering Samsung Notes handwriting - Musaab.io Reverse-engineering Samsung Notes handwriting<br>Tuesday, June 30, 2026<br>•2,508 words<br>•13 minute read
Contents<br>Who else has looked at this<br>The file<br>Reading Samsung's own decoder<br>Checking it against the box<br>Where the byte-pattern guess breaks<br>What I didn't get to<br>Why this sat private
I'd been moving off Samsung Notes and wanted to take my handwritten notes with me, except there's no real way to get them out. You can export a page as an image or a PDF, but that's a flat picture, the actual strokes stay locked in the app. The file Samsung Notes saves, .sdocx, is a ZIP, but everything inside is an undocumented binary format. I started on it in October 2025, and my decoder and a small renderer for it are on GitHub. Almost all the work went into one piece of it, how a single pen stroke is stored. That's also where the other tool that reads this format gets the encoding wrong.
It also turned out I wasn't the only one trying to get into these files. While the repo was still private, someone building a pen-plotter rig wrote to me for access. He wanted to take the handwriting trapped in his own Samsung Notes and have a machine draw it back out, in ink, on real paper. I gave it to him, and he contributed a converter that turns the decoded strokes into G-code, the instruction language CNC machines and 3D printers run on: move here, drop the pen, trace this line, lift. It even sorts the strokes back into the order you'd write them, row by row and left to right, and tunes the pen lifts, so the plotter fills the page the way a hand would instead of in whatever order the file happened to store them.
A machine drawing your own handwriting back onto paper is the kind of thing nobody had done with these notes before, and it only happened because one person could finally read the file. Your notes should be yours: not a flat picture the app hands you, not data that a single company holds the only key to. Once a file can be read, it becomes things no one planned for, and that is what I keep building toward.
Who else has looked at this
Only one earlier effort touches this file: a script from 2021 that unzips it and pulls the typed text out of note.note. It doesn't touch the handwriting. As far as I can tell, nobody had decoded the on-disk stroke geometry when I started in October 2025.
Two other efforts came after. In January 2026 TimGmbH went at it from the runtime side, hooking the Windows app with Frida and reading the point arrays out of memory while a note is open (his comment); those are the points the app has already decoded, not the raw bytes on disk, though he'd independently found that strokes are stored as deltas. Then in March 2026 came twangodev/sdocx, a Rust library that reads the on-disk format directly. It's the most complete reader of the format and the one I compare against through the rest of this post, but it gets the underlying delta format wrong, so some strokes come out distorted.
The file
Inside the ZIP you get a note.note with metadata, a pageIdInfo.dat listing the pages, one .page file per page, and a media folder. The strokes are in the .page files, which are binary and just as undocumented as everything else.
To work out the .page layout I decompiled the Samsung Notes app. It's an Android APK, so the code is Java, and jadx turns it back into readable classes, though the build is obfuscated and every class and method comes out as a single letter. The way in was to find where the app opens a .page file and follow the calls from there, into a chain of readers: a page reads its layers, a layer reads its objects, and each object reads itself out of a header, with pen strokes handled by a stroke subclass of that object. The names are meaningless and specific to this build, but the read methods give the byte layout directly:
Most of the header still reads as named fields even with the symbols stripped, because the class carries a debug dump that pairs each field with a string. One of those fields is a rectangle: four doubles read in order into an Android RectF as left, top, right, bottom, and the dump labels it "rect". So every stroke stores its own bounding box right next to its points. I skipped past it while I was after the geometry and came back to it later, because it turns out to be a way to check the decode.
The Java stops at that header. The stroke object keeps the delta stream after it as a raw byte buffer and never turns it into points; at runtime the app hands those bytes across the JNI boundary (the bridge from Java into the app's bundled C++ libraries) to the SPen native library. So the container was solved but the geometry was still a wall of 16-bit words, each one a delta nudging the pen from the last point. I spent a while trying to guess how a word becomes a distance straight from the bytes, mostly handing it to Claude to try strides and scale factors, but nothing lined up with the bounding box.
Reading Samsung's own...