Since my main development PC is somewhat broken, I installed the latest devkitARM on my laptop. I have been using the same old devkitARM version for DSx86 development since I started the project (as I hadn't dared to upgrade in case DSx86 stops working), but I had only a couple of very minor issues when compiling DSx86 with the latest development kit (r27). Also, it seems that the disk access (SD card access, actually) using libFAT is much faster in this version than in the old version I had been using, so the 0.05 version of DSx86 should load games faster than before.

My laptop is quite old and not very ergonomical to work on, so I didn't spend as much time coding DSx86 as I usually do on weekends. I concentrated my efforts on finding a couple of problems in the old Sopwith 1 CGA game. I had noticed that it does not go to graphics mode at all on DSx86, so I debugged it in DOSBox in trying to find out what method it uses to go to graphics mode. Turns out it uses IRET opcode to call the BIOS INT 10h address! I hadn't coded any support for such a weird calling method, I only checked the INT and JMP opcodes to determine if the address is in the reserved area in the BIOS where all the emulated interrupt handlers of DSx86 are.

This problem made me realize that my current method of trapping the interrupt addresses is not very robust, so I changed the method completely, now I use the undocumented opcode 0xD6 (SETALC) as a flag to mark a software interrupt entry. If the CS:IP is between F000:0000 and F000:00FF when this opcode 0xD6 is handled, it means an entry into an emulated software interrupt, else the opcode behaves like SETALC opcode normally does. This method is quite similar to how DOSBox handles the software interrupts, except that DOSBox uses the unassigned modrm bytes of opcode 0xFE to flag software interrupt entries. Having a single-byte opcode as a flag suited the DSx86 architecture better.

After that fix the game went into CGA graphics mode fine, but there was still a problem with a REP MOVSB command it used to draw the land. I noticed it used segment address B900 instead of the CGA graphics memory start address B800 to move the data, and this made me realize that I had a problem in the way I handle the graphics memory addressing. I assumed (stupidly) that the segment register always points to the start of the graphics memory and the actual location is determined solely by the index register (SI, DI or BX). Of course this does not need to be the case, so I had to fix all my CGA memory addressing so that it is based on the correct physical "segment*16+offset" address. I believe I still have this same problem in the other graphics modes besides CGA, so this I need to fix before releasing version 0.05. Anyways, after those fixes Sopwith 1 runs on DSx86, however the game does not seem to have any adjustment for the speed of the PC, so it runs really fast and is pretty much unplayable, same as in DOSBox. I don't think that is much of a problem, though, as there is a Nintendo DS version of the game.

I also went through a couple of the log files I have received from 0.04 (thanks for those!) and fixed the easy issues. I noticed a couple of unsupported graphics opcodes in the logs where I could not determine which graphics mode this happened in, so I need to add a current graphics mode indicator to the log information for the next version. Most of the issues in the latest log files are not fixed yet, though, so this work I'll continue during the next week, while waiting for the new parts to arrive for my development PC.

This post will deal with the hardware required to trigger the PS3 hypervisor memory access exploit. The purpose of the hardware is to stop the PS3 from saving a change to a value that we don’t want changed. The PS3 saves this changed value by writing the value to RAM. Therefore in order to stop it from saving the changed value we need to stop this write from occurring.

The PS3 sends the write command to the RAM over some control lines, so we interfere with these control lines when the write command is sent. The result we want is having the PS3 think it has successfully written the value to RAM, but the RAM didn’t receive the write command due to our interference and so it did not perform the write operation.

The easiest (and moderately safe) way to interfere with these control lines is to ground them. This is done easily enough by connecting a wire between one of the control lines and ground. The tricky part is timing it just right so that it only interferes with the write we want to stop, and not anything that occurs before or after this write. This might be achievable with costly equipment and a lot of work, however geohotz used the simple method of “luck”. This involves repeatedly preparing the situation to best favour the chance of overwriting the correct write command and then continually grounding a control line until either something crashes that shouldn’t or the mark is hit stopping the write operation from occurring. At this point the exploit has been successfully triggered!

Now that you know how it works it is time to implement it. A connection is required to the control line that will be grounded as well as a connection to ground. These two wires then need to be connected to each other momentarily. If you were to try and do this manually as fast as you could you might connect them for a millisecond or so, however RAM control lines are very fast so 1ms is going to interfere with way too many commands. Instead these lines need to be connected to some hardware that is able to bridge the connection between then for very small periods of time at once. Geohotz suggests a connection period of 40 nanoseconds.

There are many ways that some hardware can be made to perform this short connection. Geohotz used an FPGA he had on hand in order to do it. Others have suggested using a 555 timer, however I have not heard of anyone having any success with this method. I used a small sx28 microcontroller I had on hand due to using it for a project some years ago. It runs at 50MHz with an instruction cycle of 20 nanoseconds, which means it should be fast enough to provide the 40 nanosecond connection required.

The first step is to take apart your PS3 in order to expose the top side of the motherboard. Once you do so look for one of the following areas on it depending on what version PS3 you have.

This first picture is from an old 60GB PS3 which came with the 4 USB ports and the card readers. You can see I have soldered a wire to the side of a resistor. This is the connection to the PS3 RAM control line that you need to solder on. I suggest you route this wire down and then to the left of the two pronged power plug you can see. My wire continues downward in this picture, but I found that doing so caused interference in the wire that would unintentinally trigger RAM corruptions. To avoid this you should route it to the left underneath the power plug so that it then comes out of the left side of the PS3 case. You can use a long wire during installation, but try to keep it short when you finalise its routing and final positioning. You can see I used a hot glue gun to ensure any stress placed on the wire will not pull at the solder joint.

http://xorloser.com/blog/wp-content/...02/old_ps3.jpg

This second picture is from an 80GB PS3 with 2 USB ports and no card readers. This was the model that was out just before the “fat” PS3s were replaced by the “slim” PS3s, so it is a newer motherboard revision where there are two RAM chips on both sides of the motherboard instead of all four on one side. In this picture I have circled the trace you should solder to for your RAM control line connection. In order to solder to this I used a craft knife to carefully scratch the paint off the top of the trace to expose the copper underneath which I then soldered a wire to. Once connected you should route this wire straight down towards the front of the case to best avoid interference in the wire from other parts of the PS3. Once again try to keep the final wire nice and short.

http://xorloser.com/blog/wp-content/...02/new_ps3.jpg


Next you need to get a ground connection. This is done the same way for both motherboard versions and is very easy. You can just wrap a wire around any of the metal screws that screw into the metal shielding that covers the top of the motherboard. You don’t even need to solder it, just wrap it under the screw head and screw it into place This wire should be routed out of the console