Linux Support ...when?

[edgybugga]

Realistically how difficult/feasible would porting this project to Linux be? Being able to use this without dual-booting would be really nice.

[cristeigabriel]

pretty trivial to port. look at Skeletux for vfts if u don't know basic re. idk how well memscan works with linux, tested only pes, but c++ wrapper will require some ifdefs and a linux constructor.

[Sumandora]

Dont use Skeletux as a reference, use Fuzion and Osiris instead, they are more up to date I looked at memscan briefly and dont see any reason why it shouldnt work on Unix (maybe you have to do some minor changes), but all the signatures/offset etc are different, because Linux does use GCC unlike the Windows versions MinHook has to be replaced I heard that storing the images in the library is planed, that will also be different from Linux

I dont see a big problem porting this to linux, but might take one or two nights Hope somebody will take his time porting it ^^

[cristeigabriel]

Dont use Skeletux as a reference, use Fuzion and Osiris instead, they are more up to date I looked at memscan briefly and dont see any reason why it shouldnt work on Unix (maybe you have to do some minor changes), but all the signatures/offset etc are different, because Linux does use GCC unlike the Windows versions MinHook has to be replaced I heard that storing the images in the library is planed, that will also be different from Linux

I dont see a big problem porting this to linux, but might take one or two nights Hope somebody will take his time porting it ^^

Another thing that needs to be changed is the current follows and perhaps some dereferencing. I recommend that if anyone takes on this they just abstract such actions.

Also, please write a WIN32_LINUX function (not macro, it cannot support complex expressions), for porting, which just take 2 T&&'s (latter being Linux, and optional. You can likely achieve this most simply by having 2 functions with the same name and asserting in the first one. This is required because I don't plan to support Linux myself, and I think it'd be nice for people to know what's up.), @ whomever is going to look into this. Thanks.

[cristeigabriel]

Pinned issue given help is wanted, and, from the first update, it'll be a continuous project to keep maintenance on par with the Windows side.

[bruhmoment21]

i want to try at least to address this issue not so sure how the api works(memscan) but at least i will learn something at the end of the day

[cristeigabriel]

Thanks! You probably only want to look at the C++ api (only has Windows constructors, and will need ifdefs for includes). The whole memscan is built on pattern scanning and going back/forward in memory based on memcmp for follows. Memscan has it's own github repository. I didn't make it a submodule originally because it's an experimental fork and I was too lazy to go through with properly implementing it, so if you want to look at some further documentation look here.

The C api is fully documented too. I think the C api should be already working, but I'm not sure. If you encounter any issue you can post about it here and I'll do my best to assist.

Thank you!

[cristeigabriel]

Continuation on how memscan internally works, xrefs, the pillar for string searching. First thing I've to note is that memscan is not context aware, it does not know if the address where it claims to've found a reference is, actually, a valid reference, or merely a coincidence (which is very unlikely depending on the size of the input). When you have an address (example: 0x12345678, due to the endianness on most modern computer systems it'll be represented as 78 56 34 12 in memory (you can verify this by doing: union my_union { uint32_t address; uint8_t array[4]; }; my_union stuff; stuff.address = 0x12345678; then verifying array. Idiotically this transition is done by hand due to my short-mindedness in memscan, for which I am sorry.) That address, we expect for it to be something referenceable, and everything we find, addressing it, is inherently a reference. This is how we find strings. We do a needle-in-haystack search for a string, then if found, we take &string[0], then we pattern scan for the memory representation of the addressing (reference), and we work on the basis that we have insight on what is at the n-th match (through tools like IDA with whose order it is, obviously, compatible) and we use that context awareness we have by third party to dynamically compute the address we're seeking by visiting in a defined direction until we find our match. There's obviously fail conditions for every non-succesful scenario, but rejecting those is abstracted in the C++ wrapper which'll just return a nullopt in such a scenario, for the defined methods. Hopefully this gives more insight into how memscan functions and helps in the case of bugs.

[bruhmoment21]

Realistically how difficult/feasible would porting this project to Linux be? Being able to use this without dual-booting would be really nice.

Dont use Skeletux as a reference, use Fuzion and Osiris instead, they are more up to date I looked at memscan briefly and dont see any reason why it shouldnt work on Unix (maybe you have to do some minor changes), but all the signatures/offset etc are different, because Linux does use GCC unlike the Windows versions MinHook has to be replaced I heard that storing the images in the library is planed, that will also be different from Linux

I dont see a big problem porting this to linux, but might take one or two nights Hope somebody will take his time porting it ^^

try it should work 80%%