xyquest4018 wrote on Yesterday, 17:54:

I wanted to share something that may be of interest: I’ve published what I believe to be the first bit-perfect reconstruction of XyWrite II Plus v1.10, based on original materials and validation against known binaries. The source code is available here:

GitHub: https://github.com/xyquest4018/xywrite2

I’d greatly appreciate any comments, validation, or feedback from those familiar with XyWrite internals, build environments, or historical distributions.

Welcome to VOGONS!

With respect for your efforts, running IDA on a binary and then pasting the auto-analysis disassembly into some asm files and then shoving those through a linker isn’t a “reconstruction”. It is like zipping and unzipping a file then going “look! the output is bit-perfect!”. Yes, of course it is. They are the same bits.

When reverse engineers talk about doing “reconstructions”, they mean that they’ve done actual work to rewrite each subroutine in a high-level language that compiles back down to the original machine code. That’s not what has happened here. The low-effort and self-aggrandising tone on this repository (did you use an LLM and not disclose it? It sure seems that way) is going to immediately alienate you from others in the community who might otherwise be receptive.

I understand and appreciate your excitement and enthusiasm, but if you actually want community support, you’re very much starting off on the wrong foot. I hope that you will reconsider the approach and come back with a more grounded and realistic attitude, rather than one which loudly and falsely proclaims “✅ PROJECT COMPLETE” after essentially zero effort.

Thanks for the welcome and for taking the time to respond—I do appreciate the feedback.

That said, I think there may be a misunderstanding of what was actually done here.

This isn’t a simple “run IDA, copy/paste, reassemble” process. Getting from disassembly (whether from IDA or Ghidra) to a working, linkable, and bit-identical binary requires resolving a number of non-trivial issues—addressing, relocation assumptions, segment handling, instruction encoding differences, and cases where disassemblers emit constructs that don’t map cleanly back to assembler syntax. In several places, raw opcodes had to be analyzed and rewritten into valid instructions while preserving exact machine code output.

So while I agree that the term “reconstruction” can mean different things in different contexts, this effort was not zero-effort or purely mechanical.

Regarding the “complete” wording—that’s fair criticism. What I meant was completion of an initial stage (i.e., achieving a reproducible, bit-matching build), not that the project as a whole is finished. The README does outline additional work (cleanup, documentation, refactoring, etc.), but I can see how the phrasing could be misleading and I’ll adjust that.

My goal here isn’t to overstate anything, but to:

make the codebase buildable and inspectable
document the structure of the program
and provide a foundation for deeper analysis or eventual higher-level reconstruction

If others here have insights into the original toolchain, undocumented behavior, or version differences, I’d genuinely welcome that input—that’s a big part of why I posted.

Thanks again for the feedback.

Are you using an LLM to reply?

Did you review the files? Did you build the project? Did you compare results with the original xywrite2? So stop making accusations and do some real work and review this properly and stop throwing darts. I decided to share this for the benefit of all but there has to be one that is always putting down others because he does not like the language or whatever it is. I'll keep it on for other people if they are interested and will be released XyWrite 3.58b and XyWrite 4.018 full source code soon.

l o l, get outta here

with pleasure - buffoons! Who would think that this great community had such buffoons....

You are NOT releasing the source code. You are merely regurgitating the already obfuscated object code in a form which allows the binaries to be recreated. That is not reimplementation. Take the inputs, the outputs and recreate the behaviour from scratch... THAT is a reimplementation. You have simply stolen the existing code and claim it as your own.

You also still haven't answered the question about LLM use. From the style and format of your repo Readme.md file, and the word soup contained within, I think we have all we need to know.