(Artemis) Cheat System released

[kh2k4]

http://www.eurasia.nu/wiki/index.php...PsTwoHddViaIde refit the IDE connector on a slim for V12 / v13?

http://www.metagames-eu.com/forums/p...res-94490.html - FMCB mods are here.

http://ps2.mike-tv.com/wiki/index.php?title=Main_Page - FreeVast / FMCB concept page, down at the moment.

http://lukasz.dk/category/playstation-2/ - Has explanation of Datel's version rip-off of the Memor32.

http://www.4shared.com/dir/5795190/b...1/sharing.html - past FMCB beta's.

http://metagames-eu.com/membres_meta...jimmikaelkael/ - past FMCB beta's.

Also you can save space on the memory card by using a DVDPLx to DVDELF.BIN from a slimline of the same region when using a FAT ps2.

[Gtlcpimp]

I haven't been on much lately to notice any recent events nor view your source for this, so I'm wondering Misfire if you had taken my advice about using Kernel. I know you asked me what areas were free and I provided some information, have you used said information for your cheat system? If not you really should move it to Kernel so you have the ability to selectively hook each Syscall with a simple "if" statement. There are so many benefits to using kernel space for the cheat engine and kernel routines for a hook. I have found some time about a week or two ago and developed what I call "the hookless core". It uses a universal hook within kernel to constantly hook custom built routines stored within kernel in order to keep the ability to execute a hidden program that is still on RAM. It worked beautifully, and was tested with various games that I still own. When I get my equipment set back up I may find a bit of extra time to note it out and share the source to further help this project. However in the mean time, if you haven't already, use kernel space! It saves you so much more than you even realize (selective syscall hooking with NO SCANNING, constant hooking, NO GAME COMPATIBILITY REQUIRED FOR THE CHEAT ENGINE aka: UNIVERSAL).

[Skiller]

It saves you so much more than you even realize (selective syscall hooking with NO SCANNING, constant hooking, NO GAME COMPATIBILITY REQUIRED FOR THE CHEAT ENGINE aka: UNIVERSAL).

But it also has a Downfall
U would still need to use Activators on alot of codes that u would not want activated till later in the game or when the said Master Activator was set ..

but then again i guess thats what the C code types good for

[vampirexx]

That's a nice job!
When you will merge the technology to hack LIVE games, for example hacking infninte health or ammo while playing a ps2 game?

It woul be wonderful!!

[Lazy Bastard]

We already have that ability, for compatible games. Check out the Artemis Hacking System beta package, here: https://artemis.bountysource.com/

[vampirexx]

Thanx Lazy Bastard!
I go test the hacking tool with Metal Gear Solid 2 Substance, hope it will work and hope to be able to launch it

Sorry for my ignorance, but do I need an ethernet cable to use functions like equal to, different values, bigger, smaller etc...?
Or I can run the elf from ulauncher? Or better is it enough to load the hacking tool to memory card or should I buy a network adapter? because I dont have one

Thanx for your support

UPDATE: I tried core_launcher.elf (i put it in a usb pen and launched with ulaunch)
then the corelauncher tell me to swap disc if needed, then I tried both Metal gear solid son of liberty and susbstance,
I saw blue, pink screens but I cannot load any interface.

What's the problem, maybe I cannot load any interface because I dont have a ps2 network adapter?

Thanx

[Lazy Bastard]

Yes, you will need to connect via network adapter. You'll either need to use a crossover cable, or you'll have to set your network on the 192.168.0.x subnet.

Later versions will include a PS2-side hacking system, which will not require a network connection, but will be somewhat slower for dumping.

You should take a look at the instructions for the hacking system beta package.

[Gtlcpimp]

But it also has a Downfall
U would still need to use Activators on alot of codes that u would not want activated till later in the game or when the said Master Activator was set ..

but then again i guess thats what the C code types good for

...
Sorry but you just made no sense at all. "Master Activator" sounds like a typical code, no? If you mean by a "Master Activator" as in a hook from the game itself (which is what CodeBreaker uses, Action Replay Max uses, Game Shark uses, etc.) then no your 100% incorrect. If you mean "Master Activator" as in for a certain code you built yourself then of course, you will use it because that is a code! Codes will never change, however your requirement for a hook / ram block / list limitations are completely removed. There are approximately 300 Kilobytes of unused RAM within kernel that is free to be used by a cheat engine in any way desired. A special hook I like to use happens to be called for every Syscall interaction known to the EE. When hooked by said spot you can selectively hook any Syscall you desire with an "IF" statement rather than loading the ELF and scanning for a Syscall. All compatibility issues are removed from the cheat device, and thus making it Universal.

[jimmikaelkael]

...
When hooked by said spot you can selectively hook any Syscall you desire with an "IF" statement rather than loading the ELF and scanning for a Syscall. All compatibility issues are removed from the cheat device, and thus making it Universal.

Why would misifre loading the ELF to scan for syscalls ? aren't syscall part of the kernel ? I didn't understanded this part.

For your information, the debugger is using the kernel RAM, it has to put more than 100Kb of IOP modules in it. The debugger is hooking SifSetReg syscall to be able to catch IOP reboot and reload modules from EE, then it scan the memory for scePadRead call. It's the safest way I've found for the moment to make RPC calls...

[misfire]

As for compatibility, I'm using FMCB 1.8b on a PS2 Slim SCPH-90004 and booting Artemis 0.1 from both mass and memory card works fine.

Take care that artemis.conf and cheats.txt must be in the same folder as artemis.elf. Also, you can try to change some settings in the configuration. The engine address should be set to 0x00080000 (will be the default for next versions) and iop_reset may also be set to "true".

Anyway, like stated in the INSTALL file, it is recommended to run the current version with ps2link + ps2client. This way, you can see a lot of helpful debug messages you would otherwise miss.

[Gtlcpimp]

Why would misifre loading the ELF to scan for syscalls ? aren't syscall part of the kernel ? I didn't understanded this part.

For your information, the debugger is using the kernel RAM, it has to put more than 100Kb of IOP modules in it. The debugger is hooking SifSetReg syscall to be able to catch IOP reboot and reload modules from EE, then it scan the memory for scePadRead call. It's the safest way I've found for the moment to make RPC calls...

Apparently you didn't read my previous statement...

I haven't been on much lately to notice any recent events nor view your source for this, so I'm wondering Misfire if you had taken my advice about using Kernel.

I haven't had any time to view the source, so I was simply asking Misfire if he had taken my advice.

I have read him saying somewhere about loading the ELF and scanning for a specific Syscall to hook. This entire process is removed when you can hook from Kernel for selective Syscall hooking (which is something I have been doing in a few projects related to in-game debugging via T.V. Screen output)

[misfire]

No. The syscall vector is hooked, not the user-space call to it.

Anyway, hooking is not an issue, we might improve it later.

At the moment, Jimmi and I are working hard to make his code from Core Launcher relocatable.

[misfire]

Artemis version 0.2

Here's an update on what's been going on lately:

As ERL seems to be the perfect technology for Artemis, jimmikaelkael and I wanted to merge his code from Core Launcher v2 to my artemis-next branch and make it relocatable too. Unfortunately, it turned out to be harder than we thought, and it took us about two weeks to finally get it working. After lots of testing, we found out that the current ERL library is incompatible with some of the SDK libraries (e.g. libkernel.erl). To make a long story short, I was able to come up with a SDK patch to fix the relocation issues. (Pixel, the creator of ERL, also provided a patch but I haven't tested it yet).

We also spent a good amount of time with our ELF loader which basically replaces the original (evil) LoadExecPS2() syscall.

According to jimmikaelkael, the current artemis-next version has the same game compatibility as CLv2. It is also compatible with backups.

I'll be releasing version 0.2 next week. Stay tuned.

[Lazy Bastard]

Awesome

I still need to get around to playing with the cheat engine a bit.

[DarkSerge]

Misfire: what about dump speed? did that Improve in v2 of core Launcher?