GameGenie/ActionReplay/CodeCracker/Gameshark are all memory modifiers, and those codes you enter are usually referencing a on disc database of memory addresses+values, or are translated to the values themselves(hence usually long codes in some solutions.) The solutions either exploit something or run as friendly threads; either way they have a small program that loads them from some convenient medium.

The PS3 has locked memory, signed processes, and ASLR/address randomization(questionable but irrelevant). Those cheat solutions in the past cracked security, or designed according to vendors specs under a friendly license. Sony would have to disable some vital security to allow it, and it can't be cracked from a USB or DVD because of the underlying security that makes even a very sophisticated exploit/hack useless(The tiff exploit was a heap overflow which is about as advanced as it gets, and it just froze the PS3 like the ones on the x360 did; because of locked memory pages.)

This is why you don't see those solutions on next gen consoles. The hardware enforced DRM can't be adjusted to work with them.

I was bored and this isn't explained anywhere else on the net properly. Read the Wikipedia entry on Game Genie to see how DRM got started on embedded devices.

Last edited by 0m1kr0n (2009-08-05 20:43:09)

Powerslave wrote:

0m1kr0n wrote:

I was bored and this isn't explained anywhere else on the net properly. Read the Wikipedia entry on Game Genie to see how DRM got started on embedded devices.

I bet they get right on that...

I remember with the C64, no security at all of course for that PC, so you could "Poke" memory locations to make things work.  Man, how far security has come, from on purpose read errors on floppy to pass as an original, to what we have now.  Still, they had the same idea, you could not make a copy of the C64 game, because the READ ERRORS were on the disc, and you could not copy the read errors. So, we had to use the assembly language to REMOVE the checks from the loader...

Same with the optical drives today, they have the SAME type of protection, just more advanced. There are Errors and Data on the optical disc we cannot reproduce using a copy or backup program, of ANY type.   Making a CB360 backup is a copy, but then you need to inject the security sector, bla bla bla, so it is STILL there... 

Amazing how far it has come in 20 years...  Even the 6502, and 8088 (back when Bill Gates said 64K is all you'll EVER need); to the multi-core CPUs we have today...

Yeah I read about assembler algorithm attacks on image corruption obfuscation on old floppy software, and ROM hashing a long time ago. In theory you could do a similar attack with the PS3 by exposing the manufacturing topology or whatever, but nobody is even probing hardware let alone the BRD controller and sectors on the discs for patterns and algorithms.

I'd imagine whether it be sector spacing, or even physical impurities on the discs you could spoof it from the controller since it handles all bit streaming and buffering between the laser and the sony partner chip. I think that decryption chip removes standardized DRM so the OS doesn't have to, and with the on board SDRAM there is very little use of the 256MB SRAM.

I'm gonna try and do a universal ASIC solution the BRD board and the other NAND chips when I get another one, it's just gonna eat up time and money doing it and I don't have the budget and resources most people do right now so it's like sensationalizing vaporware.

Last edited by 0m1kr0n (2009-08-06 12:50:42)

Powerslave wrote:

0m1kr0n:  Have you seen the latest on the Xbox360 hacking scene?

More in-depth about the vulnerability from tmbinc @ xboxhacker.net...

We kept on working on this idea, and it worked out. pretty well. We use JTAG to program the DMA target addr, and then SMC to trigger the DMA read. The exploit itself is based on the old 4532 exploit.

    The magic is how we launch 4532 - there is a "backdoor" for manufacturing since CB 1920. We have been able to restore the newer CD versions for all hardware types.

    This means:
    - We can boot own code in HV context ~5s after boot, before any video output, right after the kernel runs.
    - we need to reflash the flash, and add 3 resistors for the JTAG (no modchip required! but you might want a dual-nand modchip),
    - 8498 kills this by updating the bootloader - it blacklists 4532/4548. it also does hw init stuff which might interefere with the jtag hack, we don't know yet.
    - we have a proof of concept hack, we will release it SOON (a matter of hours/days, not more - promised.).
    - DON'T UPDATE to summer 09. Did i already say this?
    - you don't need to know your cpu key. You can update to all BUT summer '09. you don't need a dvdrom.
    - It works on all xenon, zephyr, falcon, opus, jasper. Unless you have updated to 849x. Then you're screwed.

JTAG ports on the PS3?

Yeah those same guys who built off the securityfocus disclosure using the DMA-Shader loaders that exploited the syscall handling in those kernels found another way to exploit the same vulnerablity from just from a different medium using JTAG.  Every vulnerability on the x360 would be totally useless if not for the DMA launch point that exploited syscall.

The new JTAG method has been revealed to MS which isn't surprising seeing as the guys have all been consulting MS. MS made a update already that kills most of the attack vectors. I don't think they realized they got played yet.

The x360 hackers got hansel and grettled ^^

Last edited by 0m1kr0n (2009-08-18 09:43:56)

Powerslave wrote:

The thing is, the JTAG killer update was released before any mass news on the hack itself became available.  This update is the first boot-loader update ever done on the 360, to prevent the booting to XELL.   So, even if you have a Cygnos, you can't do it, because they changed the boot process. This is a clear indication that something useful could be done with it.

Still, what no one has said, is if XELL has full hardware access, and if so, this would a hack that has some substance. If it's anything like what you have with PS3 linux, what's the point?  It is practically the same thing as the KING KING exploit, except now it boots XELL before the O/S or any A/V output is done.

If you were to approach this hack, the best was it is use Cygnos, with a flashed kernel for the hack, and a switch.  The hack is said to not need hardware, which is true if you want to use the XB360 as a linux tool only, and you still need hardware to flash the nand, and the three resistors.  Also, if by any chance the nand should update with this hack in the NAND?  You're finished.

Also, I did not SEE anything on; If a Game Disc is in the drive, if it still boots to the hack, over the DVD game, or whatever.  With the original XB, the DVD drive has boot priority (which YOU could change with the hacked bios), but, if you booted with a game disc in, the game boots, not the hack, unless you changed it manually with evtool or whatever BIOS editor you needed.

PS3 still falling WAY behind...  People either don't have the time, patience, or are only focusing on the XB360 because they have already gotten way much more progress with it.  I don't think they, or anyone wants to start OVER with a better protected machine.  Lots of chatter going on, but no proof of concepts or anything worth mentioning.

Yeah the argument with the PS3 is it's not being reversed because it already has Linux support; which I think is BS. I'd bet money the person who posted the disclosure to SecurityFocus tried the PS3 too, but failed.

The latest information on the PS3 is vaguely mentioned in some reversing communities, and was started by a 'white hat' reverser who can do hardware locked TheMida and really fast malware unpacking; supposedly has a lab or other resources. He/She basically states that the PS3 runs games and Even XMB applets such as browser etc in the same mode as otheros. Then suggests the 7th core is loaded with a kernel of sorts that manages the PPE MMU and PPC security modes. This kernel is loaded by by a first stage loader internal to the CBE from the SLC NAND and sig checked with an internal hash implementation salted with the common key somehow.

I think this means the 7th core/gameos/hypervisor simply gives games access to RSX buffer operations through state flags in it's local store which are internal controlled and in no way is dictated by the PPE. All the SPEe on the PS3 have there local stores addressing controlled internally; you can write an identical hypervisor from the otheros loader and run Linux in a third state acting as a proxy for the 7th core and even adding more restrictions based on flags in your local store, and not allow outside DMA or addressing.

This is basically what I've been suggesting just in slightly more detail; it's also stated in the phrack/RISE article in some detail. I..like you, think people are going in the wrong direction on reversing the PS3 even if their intentions are to unlock RSX buffer operations for the Linux kernel.

Linux can already access everything a valid game disc can inluding the 256MB DDR2 in the RSX; only difference is push buffer restrictions. Which already exist in OpenGL they just need the abstraction layer written in the form of a driver that uses another hardware resource for blitting in combination with the RSX DDR2.

The conclusion is the 7th core gives otheros environment everthing the hardware has to offer, it just filters the MMU and controls a PPC mode. PPE has plenty of them; modern x86 chips have 4-5 privilege modes and NT and Linux only use 2 of them. Loading a backup is going to take BRD or NAND firmware reversing as we both keep stating and there isn't any other way because of process of elimination on the hardware itself. Doing any NAND overwrite attack is going to probably be more complex than BRD reversing. The fact the signature chain starts and continues from the first stage internal to the CBE really bottom lines this theory; Sony doesn't even need buffer overflow protection with the design they used it's got a unconditional hardware firewall that completely blocks any pointer overwrite from outside it's own address space. BRD or one of the few NANDs might be able to get into that address space though, or disc integrity can be spoofed.

Regarding MS insight: Most of these guys developing this have been under the thumb of MS since they first put their names on it; even consulting there. One probably leaked the information; they guys are yuppies.

Last edited by 0m1kr0n (2009-08-18 19:57:32)

knock that off both of you. your posts are in the ludicrous range of length
.

Last edited by NapoleonMikey (2009-08-23 14:52:22)

so now ur talking about taking a firmware update unencrypted it, modify it, re encrypt, and install it?
i think getting the ps3 in a sort of chain code run from the nand on boot up would be better, get the code running before the HV boots up (idont really know the ps3's boot protocol) then again u mentioned that on boot up the ps3 has a method to check signature code
btw does the nand lock up to when it hits the otheros