ghidra-scripts VS x64dbg

I've got no experience with reverse-engineering executables, but I got a bunch of code-like stuff showing up when I fed ULTIMA.EXE to Ghidra and told it to analyze it with all the flags set.

The whole game is written in C++ (game logic intertwined with graphics). Ghidra can help you deconstruct the game binaries, but you need to put in a GREAT great effort to even get a starting point. Cheat Engine has been successful for some purposes, including an AI enabling utility for multiplayer (use with great care!).

Ghidra: https://ghidra-sre.org/, https://github.com/NationalSecurityAgency/ghidra

What I think you’re talking about is reverse engineering. It’s basically taking a program and analysing the compiled code to attempt to find out how it works. It’s a fairly expansive topic, and fairly tricky to do but look at anything to do with Ghidra to get started.

Oh also just as an aside Ghidra is a really cool free tool developed by the NSA which can reverse engineer software by looking at its executable and recreating the C code from the instructions and static data within. It's another way to get familiarized with the relationship between C code and the instructions it compiles to.

There exist decompilers and other tools for helping make sense of assembly and that can automate some of the conversion back to higher level languages. In my brief involvement with Slippi I used Ghidra - a tool developed by the NSA, to do some of that kind of work, which I found a little amusing.

It's likely a binary file that's improperly being interpreted as Unicode by the text editor. If it's an executable file, you can use Ghidra to disassemble and analyze it. There may also be some interesting ASCII strings that would reveal its purpose. My guess is that it's a Windows version of Unix "tee" program which will write stdin to a file and stdout simultaneously.

On the other hand, this slick "Ghidra" webpage looks suspicious. It's probably written in Typescript on Electron!

I have never heard anyone say anything good about the Visual Studio debugger before. Now, I'm not a Windows person but I'm not gonna argue for gdb or lldb here. RemedyBG and x64dbg are the two debuggers I've heard good things about though I've never used them because, again, not a Windows person.

[1] https://remedybg.handmade.network/

[2] https://x64dbg.com/

I'd help you out but because of circumstances I have no laptop with me. You need x86/x64 debugger to do this. This one for example Find a registration procedure and look for possible brenching to other parts of code in assembly. It's probably somewhere in the beginning. Exclude code validation and export new program version.

One interesting thing you can do is download an app like https://x64dbg.com/ or cheat engine, which will let you see the memory. You can look at the process for something you’ve made and explore it. Log a memory address from your app then go find it in the tool and interpret the bytes as an integer. Find a string and see how that works. Find a pointer, read the address it’s pointing then go look at that address. You start to see how different containers store data. I find it fascinating.

If you want to also do dynamic analysis (debugging) you can use https://x64dbg.com.

close origin and download this debugger https://github.com/x64dbg/x64dbg/releases

.exe is a complex format and not something you're going to extract raw instructions from using a hexdump. What you need is a "disassembler". For Windows I'd recommend x64dbg.

Patch the DayZServer_x64.exe, change "test al, al" to "cmp al, 2". i used x64dbg (https://x64dbg.com) a good video for the whole process: https://drive.google.com/file/d/1F1A0lpumREPXtVeoTMq1HiEnvaZp-NUU/view