Closed ArcadeHustle closed 4 years ago
Thanks, It's interesting to see that only such very small changes are needed to make it work on macOS as well :)
I never really looked into it myself since my experience with macOS just have been it's not worth to support it for me as an individual doing development and research. There is unfortunately zero return of doing any research on the mac platform. The old mac I have I kinda can't upgrade since I want to be able to demo some older CVE's I have on that older versions of the platform. So basically I haven't been too keen on paying yet another $2000-$3000 for new apple hw just to get my tools working on their platform...
Anyway, super thanks for showing it's possible. I really should be looking into this :)
Right now I've been advised by a law firm not to accept new external contributions though. Not until I've cleared up a few issues with regards to copyrights and such. Hopefully it shouldn't be too long.
Fully understood... I think with a quick fix on the linking routine it should be fine. Good luck with the GPL lines in the sand! Thanks for what you've done thus far. It would be sweet if there were some older XP binaries too FWIW, I know low return for you. High return to the arcade research community as lots of old machines run on XP still. =] Cheers.
What do you mean with XP binaries? like running PCILeech on WinXP? or targeting WinXP as the victim - i.e. inserting kernel modules as such?
basic memory dump support via the LeechAgent. I think you have Windows 7 set at the minimum target level for the compile.
winusb.h isn't included in the standard headers for winxp, but there may be a way around it and compile it for xp anyway; I'll look into it for the x86 version of leechcore/leechagent to see if I can manage to do this anyway in a fairly easy way without having to put a gazillion #ifdef -clauses in my code. The WinUSB seems to be the only thing holding it back. But no promises and it's probably another month or so to go before I'll publish a new release.
yeah, it should be possible to add XP support; I'll need to add a few workarounds; but it's relatively minor work so I'll look into this for the next release. for 32-bit version only.
sounds good brother. Much appreciated. What is the difference in adding 64bit, would it matter at that point at the 64bit can run 32 bit exes. Does it change the access to memory space?
XP was 32-bit only, except for an experimental 64-bit version with pretty much zero market share.
I've looked into this more now, and it looks like I have to redo large amounts of code to be able to support XP. It's doable; but I'll have to change the WinUSB stuff around to avoid imports; and then I'm still going to have a lot of missing imports like the one below still:
It's certainly doable; but it will be quite messy; and I'm not ready to mess around with my code and pollute it with a lot of xp-specific workarounds for this. If you would like to built your own and publish it that may be an option though.
I'm doing major reworkings around the LeechCore API which I plan to release in a version 2.0 soon, so it will make sense to wait with XP support if you're planning to look into it yourself.
About the mac; it seems to be quite easy; but right now I'm not going to pay for a mac just to test this on :\
I'm more than happy to test a Mac fork on your behalf. =] I'll look at XP support. Do you have any more notes on the nuances involved?
do you have a .diff of your start? perhaps toss it in a branch , so I can submit PR's against it till it works?
The changes I'm planning on right now are quite massive; so let's hold off doing anything until the new release is done. The XP stuff I did was mostly around copying missing headers, editing visual studio paths and such, so not much code changes as such... But lets revisit this topic a bit later when I'm done with the other changes; a separate XP fork may be a good idea :)
cheers brother.
I've given this some thought; and I've decided against XP support for now. It's a real hassle for me to implement it even though it in theory it's probably possible. Also I don't want to end up with #ifdef ridden spaghetti code to support a relatively minor platform. I don't have an issue with if you do fork it and rearrange stuff to make it to work on XP though đź‘Ť
About macOS; with their move to ARM I most probably have to get myself a new expensive mac if I'm going to be able to support it in the long run so I'd also prefer not to here. The bulk of my things revolve around the windows-only memprocfs also so it makes mac support even less interesting. If I had the time I'd do it; but with this being a hobby project with just a few, but still awesome, sponsors I don't see how I can justify putting hours and money into mac support - and even more hours supporting it in the future.
Thank You for showing me it was possible though :)
That’s a shame! Back in the pile of hardware that kinda works, but just not for my edge case.
Sadly this makes the tool nearly useless for what I purchased it to do. Adding it to my list of back burner forks probably isn’t a realistic thought.
Thanks for what you shared. Wish it worked for me!
osx.txt
The linking is off a hair.
$ make cp ../files/leechcore.lib . |true gcc -o pcileech oscompatibility.o device.o pcileech.o executor.o extra.o help.o kmd.o memdump.o mempatch.o statistics.o umd.o util.o vfs.o vmmprx.o -I. -D LINUX -L. -l:leechcore.lib -pthread
pkg-config libusb-1.0 --libs --cflags
-Wl,-rpath,'$ORIGIN' ld: library not found for -l:leechcore.lib clang: error: linker command failed with exit code 1 (use -v to see invocation) make: *** [pcileech] Error 1