News: 11 March 2016 - Forum Rules
Current Moderators - DarkSol, KingMike, MathOnNapkins, Azkadellia, Danke

Author Topic: Playstation 1 hacking  (Read 10303 times)

slidelljohn

  • Sr. Member
  • ****
  • Posts: 331
    • View Profile
Playstation 1 hacking
« on: January 26, 2014, 11:16:28 pm »
I was gonna see if someone knows some good tools and documents that I can use for playstation 1 hacking. I did some searching but I'm having a hard getting started I already know snes programming and c++ so I should be able to pick it up pretty fast. I want to try and hack mega man x3 on the playstation 1 because the Super Nintendo is not powerfull enough to properly run any mega man x game without glitching plus I just need a more powerfull system for what I want to do to the mega man x series. If I can just edit a few bytes in a hex editor and save it to a disk to play on my modded playstation 1 that would be a huge step forward. Any help getting started would be much appreciated.

FAST6191

  • Hero Member
  • *****
  • Posts: 3023
    • View Profile
Re: Playstation 1 hacking
« Reply #1 on: January 27, 2014, 09:39:28 am »
PS1 games come in standard ISO form so find something to pull apart them, the raw reads (otherwise known as LBA reads and sometimes DMA reads) concept did exist on the PS1 and was used a few times though so you may have to deal with that (for megaman X3 I have no idea). However the idea of a standard iso did not really exist in the PS1 era so many isos you find might be in the many and varied formats used during the time (clonecd, normal iso, cue files, nero/NRJ, cdrwin.....), fortunately most of the paid tools like magiciso, poweriso, ultraiso and that sort of thing, which otherwise are the best option for fiddling with normal isos, will read and probably convert others.

Tools.
PS1 emulation is great. PS1 debugging if you stick to the likes of epsxe and psxemu is not up there with the other consoles though it could be far worse (it is a bit old and if you already know the SNES then a bit hand holdy* but then not an awful lot happened since-- http://www.zophar.net/forums/showthread.php?t=13521 ). However I have yet to put http://nocash.emubase.de/psx.htm through its paces as far as debugging goes, his GBA and DS stuff is as good as it got for those consoles (and I am hearing good things about his SNES tools as well) and it looks like broadly similar functionality here.

*MIPS and SNES CPU are not the closest but if you understand the idea of assembly rather than just the instructions you should be OK. Someone linked up http://cad6.csie.fju.edu.tw/comorg97/download/MIPS_Assembly_Language_Programming_(2003).pdf the other month and it worked quite well for me. Should you prefer something else then even though MIPS is not as popular as X86, 68K, Z80/8080 or ARM there is enough using it that you have options.
 
At a glance http://nocash.emubase.de/psx-spx.htm is not quite as all encompassing as his GB/GBC and GBA/DS documentation, however if you have questions after that then it will probably be very specific or you wanting to know how things play out in the real world (it is a bit light on worked examples). This place ( http://www.romhacking.net/?page=documents&category=&platform=17&game=&author=&perpage=20&level=&title=&desc=&docsearch=Go ) does not exactly lack for them either, http://psx.rules.org/psxrul2.shtml and http://www.geocities.co.jp/Playtown/2004/psx/ might also be worth a look.

All that a quick scan says windows had a version of X3, such a thing might represent an easier option for all this even if you have to "restore" things to how they were on the SNES.

Bob Liu

  • Sr. Member
  • ****
  • Posts: 253
    • View Profile
Re: Playstation 1 hacking
« Reply #2 on: January 29, 2014, 04:28:54 pm »
What does this ps1 debugging allow you to do exactly.

FAST6191

  • Hero Member
  • *****
  • Posts: 3023
    • View Profile
Re: Playstation 1 hacking
« Reply #3 on: January 29, 2014, 06:16:58 pm »
What is the feature set of the main PS1 debuggers compared to other systems or what is debugging in general?

The PS1 stuff is not as good as the likes of FCEUX but it can do a lot and looking at the three main options you have most of the normal things covered. The PS1 piped most things over 3d though, even what you think is 2d, so you are a bit more limited compared to some of the things you could do in 16 bit and older systems as well as the handhelds. Certainly nothing truly exotic though, for instance if you want to do return oriented programming on the PS1 you are probably going to have to invent it there yourself where I could probably point at something on the PC (why you would do this for the PS1 I have no idea). Indeed I would be quite surprised if you could step backwards (some emulators will store everything that happens and allow you to rewind time).

More generally debugging, at least when a ROM hacker speaks of it, is a powerful set of tools, techniques and ways of thinking that allow you to reverse engineer ROMs. For example the technique known as relative searching will often give you the data necessary to make a table for a script, however it is a shot in the dark based upon what has happened (albeit hundreds of times across time, consoles and developers as well as common programming languages being designed to do it) before and could well get you nowhere. Debugging would straight up tell you, assuming you were skilled enough at it to make it happen.
I am not sure how to proceed from there, many would go into tracing, indeed it is the impulse I have, but looking at it another way most of debugging could be viewed as tracing of some form.
Taking a step back though debugging will at the crudest level allow you to look at the memory, the registers of a CPU, the flags of a CPU.... basically everything that can be changed so as to allow the program to run, better ones will decode this in a variety of manners (disassembly, register decoding if you are looking at a purpose specific register), decode the contents of the palettes, graphics, backgrounds, audio channels...... You can also set instructions to stop when certain things happen (breakpoints) or log them. Better debuggers allow you to set more exotic breakpoints, indeed certain emulators will even interface will full programming languages (sometimes their own scripting engine, in the likes of FCEUX and Desmume it is Lua). As well as decoding, stopping and logging you can also manipulate parts of the system, this is what the final part of the debugger does, the basic stuff is memory, sound channels and registers, more advanced stuff is actually being able to write assembly code into the running game and have it work from there.

Generally viewing memory, registers and basic disassembly and tile/palette/background viewing is the first step towards being called a debugging emulator, some stop here and frankly they are not really that useful if you want to do more than make basic cheats or rip sprites. Better ones will

I tried to list most of the big features for debuggers, including all the types of breakpoints I could think of that have been used over the years, to have in http://www.romhacking.net/forum/index.php/topic,17234.0.html
A further tool that is very popular among hackers is called IDA which has a lot of other features as well, however it typically does not do full emulation like you might seen in an emulator so at points it is somewhat lesser. Of course full computer emulation is possible so that is used at times, likewise for emulators without debuggers, or when there are better game playing emulators than there are ones with debuggers, you can use PC debugging techniques to read them, popular cheating tools like emuhaste and artmoney being good examples of the concept being taken to an advanced/specific level.

To just cover tracing though. If you want to edit a sprite it will have to be loaded into memory, some rare systems will instead load a reference to the ROM image but either way something in the writable portion of a console will have the relevant info. You then go back to a point before it is visible on screen (in theory it could happen right at boot but in practice it does not, not being on screen and not being in memory are two different things though) and say "when this value gets written into memory stop the game and tell me". When it happens you may have got lucky and it is a direct copy from a place in the ROM, other times you might find a decompression has happened first, other times something old was copied from memory and edited a bit along the way so you get to repeat the process with the results there until you get back to the ROM. For the latter part you will have to observe what happens during a set of instructions which is why tracing, when viewed from a certain angle at least, is so encompassing.
Naturally tracing is made considerably easier by assembly knowledge, though more commonly learning to trace leads to assembly knowledge if you did not have it before, and is very powerful which is why hackers that know assembly can get on with things so well.

Bob Liu

  • Sr. Member
  • ****
  • Posts: 253
    • View Profile
Re: Playstation 1 hacking
« Reply #4 on: January 31, 2014, 11:04:24 am »
That's alot of info, I read elsewhere on the internet that people have used it to detect the games text that appears when it's visible on the screen and where it's located.

FAST6191

  • Hero Member
  • *****
  • Posts: 3023
    • View Profile
Re: Playstation 1 hacking
« Reply #5 on: January 31, 2014, 12:44:24 pm »
Debugging, once you get beyond the cursory stuff, is an involved technique that kind of needs a lot of info to work it properly. No real way around that really.

Your example would be an example of tracing though. I tend not to see text found using it, no great reason than it is often easier to find by other means. That said finishing up a text hack, figuring out all the little specifics and more, as well as maybe adding something to the text engine, is a great job for a debugger.