Hardware based memory dumping/searching...

Has there every been any public developments relating to hardware based memory manipulation? For example, an interface soldered directly to a motherboard that has full R/W access to the RAM while the system is running? I read somewhere that this is the method CMX (creator of CodeBreaker and CMGSCCC) used for hacking PS2 codes. I'd imagine it would have also been done for systems like the Dreamcast, since the only other would have been through an emulator (I think?). Geohot did RAM dumps on the PS3 with external hardware.

So, if information about this thing isn't readily available, how hard is it to do? This could be used for cheating and dumping purposes.

 

I kinda know what you mean. I think SilverBull's Kermit is pretty close to that without soldering anything to the machine. L_Oliviera has youtube videos of him manipulating live memory of the machine while it's running.

There is an option to dump the video ram, rom images e.t.c., SilverBull will be able to clarify more on this subject.

Kermit is a very powerful tool.

 

I've used Kermit before and its very useful. iirc there were some compatibility issues with some games. That's where a hardware solution would come in handy. I'm in no way requesting for someone to make this, but I'm wondering if it's even possible. Moreover, maybe the same ideas could apply to the dreamcast or other systems. Interact, datel, blaze, etc. must all have used in-house, custom tools. Considering these companies were able to whip out codes for practically every game on certain systems, I doubt they relied on software.

 

Probably just really awesome programmers.

 

It's possible that the cheats were made only with software, disassembling game code doesn't require real time access to memory.

If you want full read/write access to memory then it's going to be tricky, as you will need to kick the processor and dma off the bus while you access ram. Even if you figure out a way to do it then because the memory controller is generally built into the processor then you'll have to deal with refreshing the ram while it's off the bus.

You could replace the ram with your own that is faster so you an interleave access, but then it's getting even more complex.

For read access you would probably snoop for writes and keep them in your own ram.

 

Link?

 

http://www.youtube.com/watch?v=Fx47jRF6fwU


Edit: And that's the REAL thing connected to a TV capture card, not an emulator.

 

That does rule

Would like to try that while running a game and causing all sorts of problems :lol:

 

PS2 games are doing weird things, as am I. I'm glad it works at the level it does, but there is certainly room for improvements. If you have ideas, please feel free to contact me via PM.

There is a hardware solution for the PS2, and its called a "PS2 TOOL". The official debugger stubs stay in memory, in a similar (but more compatible) way then Kermit tries to do. If we could exchange the MPROM of real consoles, it would be easy to add real debugger stubs as well. Combine that with a real open-source modchip to control the mechacon, and only the sky is the limit. The lack of an additional communication channel is a problem, but nothing that soldering to the SSBUS connector could not solve.

Please note that Kermit already allows certain things that TOOLs do not (well, very few, but anyway). Did you ever try single-stepping over SifIopReset? :gravedigging: Or single-stepping through KELF decryption?

Be my guest. Happy screwing around :lol:

 

Single stepping through kelf decryption, nice! I really need to get a FireWire cable so I can actually use Kermit. Do you have any plans to make kermit opensource? Entirely your decision, but If not, what's the newest version?

 

I need to learn how to do that.

I was also wondering how far you have gotten on the next version?? And is there any chance of a Linux version of Kermit??

 

The newest version is just a maintenance release with two ODEM fixes: support for games that launch other ELFs via LoadExecPS2 (like the .hack series do; their language select screen is one ELF, the main game another), and support for a configurable delay for the CDVD completion timer (with the right value, this fixes the sporadic freezes in Shadow Hearts Covenant).

This version is not public yet. The latest public version is the same one currently linked to in the forum.

Sorry, but I'm not going to make Kermit open source any time soon. Also please don't count on it to ever be open-source.

There have been other things in my life, so unfortunately I cannot put that much effort into PS2 programming anymore than I'd want to. There is no Linux version in the making, nor is one planned. The current .NET code is highly dependent on Windows, so I don't expect it to be easily portable. A "native" Linux version would probably be better, but I have neither the time nor the expertise (yet?) to do that. :shrug:

 

I knew that would be the answer. I myself don't care about it being open source or not.

I know exactly how you feel.

That's a pity. I was just thinking that it would be pretty cool to use Kermit on a TOOL while running the SDK packages from Linux. Then we wouldn't need a dual boot computer (or virtual machine). Nevermind no biggie, was just wondering.

I was also wondering if you'd seen CL Debug?? It's an on screen in game debugger (using the TV not computer) and was thinking that you could maybe add something similar to Kermit so you've got a computer version and a TV version :shrug:. Might be too hard to implement, but it's just a suggestion. I'm not even a programmer yet so I wouldn't really have a clue.

 

You could solder a fpga board to the bus since the ps2 shouldnt be that extrem fast and code it up to first dump and than one the fly patch your stuff, but that requires a certain amount of tech skill to do o

 

If you want a little insight as to how Datel hacked their codes, read this page onwards: http://psx-scene.com/forums/f6/ps2-dump-code-type-1-released-36555/index2.html

You're probably aware of these programs, but you can use CL-Live Debug or PS2rd + PS2CC to search for codes on the console. The key feature missing in PS2 hacking is breakpoints. PS2rd has the ability to set breakpoints, but it's only available in an unreleased build. Misfire has not been active in a long time, and a couple of his sites have been removed for whatever reason.

 

RDRAM is very fast and FPGA are probably slower than you think.

 

That's one of the things KERMIT does allow for, if you use it with DECI2 enabled. DECI is the custom debugging protocol SONY uses on their development tools. And the whole point of KERMIT is enable that on retail hardware. :thumbsup:

Not only to mention that taking gzipped ram dumps on a memory card is stone age compared to LIVE MEMORY editing and full dumping of both EE and IOP memory (It takes no more than 10 seconds to dump the whole EE memory, including Kernel regions, something you might not be able to do the MC hack) ...

 

Afaik the ram of a PS2 is just 400 mhz on dual channel. I think some of the later Altera Stratix should be able to handle that speed.

 

Yeah, they probably have a flip-flop toggle rate of 400 MHz. That doesn't mean they can implement a 400 MHz bus arbiter. It's even less feasible if the clocks aren't synchronized, for that you'd need to scale for a factor of 5-10 to account for metastability.

 

You're right. I forgot KERMIT had those features. Thanks for the reminder.

All good information to know.