-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
OpenWebView2Loader
An open-source reimplementation of the Microsoft WebView2Loader, for using Edge WebView2.
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
Seems like a neater alternative than the linker scripts used by most projects.
> Creating libraries, by extracting parts of a program and reusing them in another context;
This seems like a big win when creating (un-)packers for custom formats. For this game after isolating the routine that decompresses the textures it was so annoying to not mess up the logic - https://github.com/krystalgamer/spidey-tools/blob/master/psx...
I've been working on a similar project (LEGO Island decompilation). We've developed an extensive set of annotations and corresponding tools that facilitate matching the assembly/binary:
https://github.com/isledecomp/isle/tree/master/tools
We've been considering creating a separate project/repository for the tools since they might be interesting for other projects such as yours as well.
> We've been considering creating a separate project/repository for the tools since they might be interesting for other projects such as yours as well.
Happy to use anything that makes my life easier! I myself also started to prototype some tools - https://github.com/krystalgamer/spidey-decomp/tree/master/to... - but didn't get much far. I see there's quite a bit of overlap so I might integrate them on my workflow
Curious to know about `patch_c2.py` it mentions a bugged warning. Is that patch just to remove the warning or something deeper?
I've been working on my own reverse-engineering/decompilation project (_Tenchu: Stealth Assassins_) and I've created a Ghidra extension that can export a program selection as a working, relocatable object file [1].
I've had some really good results on x86 since writing an analyzer for an architecture where relocation spots target 4-byte immediate fields inside of instructions is fairly easy. Unfortunately, the PlayStation uses a MIPS processor and writing an analyzer for split HI16/LO16 relocations is proving to be a devilishly tricky problem.
I got it to a point where it works well enough on MIPS most of the time, but there's always a new weird edge case hidden inside a function thousands of instructions long where it breaks down...
[1] https://github.com/boricj/ghidra-delinker-extension
I've been doing a bit of research on and off for the past few years on decompilation and it's definitely challenging to decide how close you want to go to matching. If you can get the exact compiler and exact compilation settings, it's totally feasible to do matching decompilation, and if you're able to make this somehow incremental such that you can incrementally work up to 100% matching over time, it seems like a really good approach, but it requires a lot of groundwork and understanding how the compiler and linker really work. In the process of matching compilation of functions on a binary I was analyzing that was compiled with Visual Studio 2003, I realized that very subtle differences can cause e.g. different register allocation, even in an old compiler with dramatically less sophisticated optimization passes.
Anyway, I guess this tangent is really unrelated, but I think more people should be embarking on decompilation projects. It's very fun, and it's uniquely rewarding if you manage to get some non-trivial decompilation of code to work properly.
I had one odd use case for decompiling that was actually, as far as I know, completely licit: WebView2Loader. Microsoft distributed the WebView2 SDK as 3-BSD so that you could integrate it into your applications without worrying about licensing, but the glue logic that actually interacts with the WebView2 installation and instantiates the COM objects is closed source. But... since it is closed-source 3-BSD, without a EULA... we can reverse engineer it. It being a relatively small shim, I did just that[1]. This was an easy exercise armed with an interactive disassembler, and since it was relatively simple and very small I didn't need to bother with matching anything: I just roughly replicated the behavior instead. The use case for this was allowing people to make WebView2 bindings that didn't have any external dependencies; the OpenWebView2Loader code was ported to Pascal and Go by others, making it possible to have pure bindings that don't require any C code or external DLLs and can directly talk to the WebView2 installation. There's now a static copy of the WebView2Loader with the SDK, which obviates some of the use of this, but this is still a nice approach for Go where you can entirely avoid CGo or messing with weird object format conversion. (It's way better than my original approach for WebView2 in Go, which is to emulate the Windows linker to link and execute an entirely in-memory copy of the WebView2Loader DLL using a lot of unsafe code. That also works, but it is much more bug prone and frankly horrifying.)
[1]: https://github.com/jchv/OpenWebView2Loader