We rebuilt the Lua-based AutoPlay application CODE RIAD as CODE KOURCHAL, an offline Arabic desktop application using Electron. The work began with a legacy executable and extracted project material. It became an exercise in recovering behavior, checking content and designing a maintainable replacement.
REA helped inspect the original executable's resources. Readable Lua from the supplied extracted project, configuration files and recovered media supplied much of the application-specific evidence. The new Electron implementation was written and tested separately.
What REA actually established
The recorded REA resource inspection identified the original executable as PE32 and retained resource ranges, hashes and icon references. That gave us a concrete identity for the artifact and traceable resource observations.
Deep native analysis was unavailable because the session had no configured Ghidra or IDA provider. We did not execute the original application during this reconstruction. The case therefore does not demonstrate a complete native decompilation, a live comparison against the original UI, or an automatic executable-to-Electron conversion.
That boundary helped determine where to look next. The supplied extracted project contained readable Lua in _proj.dat. We could study relevant logic directly and compare it with the separate question and media files.
Recover the meaning of the question bank
The bank contained 924 question IDs across 35 series. Two similar-looking data files played different roles: series.ini.txt supplied the number of choices, while series1.txt supplied the correction answer sets.
This distinction mattered immediately. A question with three available choices does not necessarily have three correct answers. The recovered bank included questions with several correct choices, so a single-selection interface would change the exam's behavior.
We implemented exact answer-set comparison. Selecting one correct answer out of two is not the same as selecting the full correct set. Tests needed to cover missing selections, extra selections, skipped questions and complete matches.
The specification emerged from the relationship between the Lua logic and the data. Neither a filename nor an isolated example was enough.
Recover media, then validate the recovered files
The historical media could not simply be treated as ordinary image and audio files. The extracted Lua contained a media-decoding routine, which informed a separate recovery process while preserving the originals.
The recovery report records 3,662 decoded assets, including 924 question visuals and 924 narrated question audio files, alongside correction media. Each recovered image underwent structure and full pixel decoding checks, including animated frames. All 1,812 recovered Ogg audio files passed full FFmpeg decoding with zero reported errors.
Those checks establish that the files decode. They do not establish that every spoken explanation is correct, or that historical material matches the current syllabus. Audio semantics and the full bank's educational accuracy remain separate review tasks.
Keeping source and recovered-file provenance made a failed playback problem distinguishable from a content disagreement.
Rebuild the application around explicit states
The replacement introduced an Arabic RTL interface and an offline Electron desktop structure with an isolated renderer and preload boundary. Local media and resources support use without a network connection.
The final classroom workflow distinguished Normal mode from Datashow. Normal accepts multiple selections or an unanswered advance and records a personal result. Datashow supports paper responses and does not create personal grades.
Both modes reach an end screen before corrections begin. Starting corrections is an explicit action, and correction controls are read-only. These details prevent navigation from silently changing an answer or recording a classroom presentation as personal performance.
Persistence needed similar precision. Resuming a question, an end screen and a correction screen are different states. Migration also had to preserve existing progress rather than overwrite a newer profile with legacy data.
Treat a contradiction as a decision to resolve
One question exposed a conflict between the original correction key and recovered scoring logic: series 12, question 23. It was initially excluded from grading while the disagreement was investigated.
The later approved correction uses answer 1. The override records provenance, and contradictory historical correction media is excluded from that question's active correction flow. This is an intentional reviewed change, not a claim that every historical answer was independently revalidated.
The recorded modern-runtime smoke check for version 1.3.0 verified that the response survives reload, the corrected explanation appears, conflicting media is absent, and the complete series can score 40/40 including the corrected question.
What the verification supports
Saved core-test and packaged-runtime reports cover scoring, persistence, migration, mode behavior and media playback at their documented revisions. These are historical verification results from this development machine, not fresh tests on every supported computer.
The modern correction check and the Windows release artifacts also have different scopes. Packaging a Windows 7 edition does not prove that it runs correctly on an actual Windows 7 machine. That execution remained unverified.
The app's historical media retains original embedded branding. Reconstructing software behavior does not settle redistribution rights for recovered content, so this article is a technical case note rather than a public distribution offer.
The lesson I would carry into another rebuild
Separate recovered facts from product choices. Keep disagreements visible. Test the transitions people depend on: answering, closing, reopening, completing and reviewing.
The same distinction matters in the document workflows behind Kaliits. Recovering an old import rule can explain existing behavior; the process owner still needs to confirm whether that rule should govern the new workflow.
For REA's broader role, see the official project documentation. In this case its contribution was bounded resource evidence, combined with extracted source and independent implementation work. That combination produced a useful rebuild without requiring us to pretend the investigation established more than it did.
Case evidence reviewed on 15 October 2026: reconstruction and media-recovery reports, the version 1.2.0 release report, and the version 1.3.0 modern correction smoke record. The early reports describe the question's initial exclusion; the later correction record supersedes that specific state.