Sponsored Links

Sponsored Links

CodeWizard PS3 1.2.1 (PPC Assembler) by Dnawrkshp is Released


Sponsored Links
54w ago - Following up on his NetCheat for PS3 updates, today PlayStation 3 homebrew developer Dnawrkshp has released what he calls CodeWizard PS3 1.2.1 (PPC Assembler) followed by v1.2.4 with details below.

Download: [Register or Login to view links] / [Register or Login to view links]

To quote: CodeWizard PS3 is a makeshift PowerPC Assembly assembler, disassembler, and emulator (emulates the supported instructions).

It allows you to write the assembly and assemble it into NetCheat format, byte array (C#), and a hex string array. It allows for multiple tabs, coloring, labels, custom psuedo instructions, and an auto complete menu.

Assembly:

Format:

Instructions must be lowercase (addi, not ADDI).
Psuedo instructions must be laid out like so:

[Register or Login to view code]

Registers prefixes are % and $, but you can have no prefix. Registers must be lowercase.
Decimal values must have no prefix.
Hexadecimal values must have a 0x or $ prefix.
Single line comments start with //
Multiline comments start with /* and end with */
Label declarations must end with : and label referring is just the label name

[Register or Login to view code]

CodeWizard supports a limited number of operations (this is why it is in beta):

[Register or Login to view code]

Conditional branches use labels or offsets. The offsets are relative to the current address. Unconditional branches use labels or addresses. The addresses are not relative.

label1:

beq 0x4 //Branches if cr0 is equal to the next line
bl 0x001ADCC0

beq label1
bl label1

Instructions like stw (stw rA, 0xXXXX(rD)) must be laid out like shown. You can't write "stw rA, rD, 0xXXXX" or anything similar.

Special Instructions:

"address 0xXXXXXXXX" - Sets the current address in the assembler.
"hook 0xXXXXXXXX" - One time use, sets the passed address to a *branch* to the first "address" instruction (hooks the beginning of the sub to the passed argument).
"hookl 0xXXXXXXXX" - One time use, sets the passed address to a *branch and link* to the first "address" instruction (hooks the beginning of the sub to the passed argument).
"setreg rD, 0xXXXXXXXX" - Sets the register rD to the passed 32 bit immediate. Doesn't have to be hexadecimal.
"hexcode 0xXXXXXXXX" - In the assembled code, the value will be equal to the passed 32 bit value. This is great for unsupported instructions.
"import [PATH]" - Imports the file at [PATH] into the subroutine at assemble time. Puts it after the already loaded imports.
"float [FLOAT]" - Inserts into the assembled code as assemble time the hexadecimal version of the float specified. Ex: float 1.23 => 3F9D70A4
"string [STRING]" - Converts the string into a hex version and inserts it into the code at assemble time. Ex: string aBbCcd => 61426243 :: 63640000

Output Type:

NetCheat format; 2 ADDR8 VAL8.
Byte array: byte[] NAME = { 0xBYTES ... }
Hex string array: BYTES ...

[Register or Login to view code]

Disassembly:

The format must be in NetCheat PS3 format. If it is not then you must use the Conversion form under Tools. Labels and address instructions will be used as much as possible. Only other thing is that it erases the currently open tab if you accept the prompt.

Emulation:

Images:

Please understand that the emulator is very basic and is just to find errors in the assembly. It only emulates the assembly.

Registers are completely modifiable during execution and turn red when they are modified by the code. You may switch between the register types by clicking on the lable above the register list. The stack pointer (register 1) is set in the options menu and is defaulted to 02000000.

Controls are fairly simple. Aside from the buttons, you may press F11 to step into. The debug box just displays any errors that occur like unsupported op or invalid memory access.




So I am releasing this as beta to get some feedback as to what instructions should be added. Also if you have find any bugs or have questions please don't be afraid to reply.

1.2.4 Changelog:

Fixed a bunch of assembling bugs that were caused by new NC format
Fixed bug where new tab wouldn't have autocomplete
Fixed bug caused when a pseudo instruction has no arguments can't be used
Cleaned up emulator and assembler a bit
Added AutoIndent
Added tab support (cleaner formatting)
Added new instructions: divw, lwzx, stwx, ldx, stdx, lfd, stfd
Added Updater (identical to NetCheat PS3)

Below is a Hooking Methods Guide from therifboy, as follows:

Note: you will need some knowledge of ppc for this. I'll try to explain some methods of hooking as good as possible. But it still can be hard without knowledge of ppc since you will need to reverse the number of arguments and also the type. I will not explain this process.

Download: [Register or Login to view links]

METHOD 1: Intercepting calls of separate functions

This method is really simple. All it does is edit the call to make it branch to a subroutine you have written inside the .self. Note that the difference between the address of the call and your subroutine can't be bigger than 0x1FFFFFC. That's the range of a 'bl'.

If I press X on that call I can see that subroutine is referenced multiple times, but we will be intercepting only the calls coming from the subroutine i'm currently in. In this case sub_23286C. The function I will be hooking is cellHttpSendRequest btw.

This method is not the best one. You will either need to write the subroutine by hand and then copy it somewhere into memory where it can be executed, or write it in C/C++, compile the code and then edit the addresses by hand. Your code should look like this:

[Register or Login to view code]

What I mean by edit addresses by hand is that you will need to edit the opcodes for the call to printf to make it call the printf function inside the .self.

METHOD 2: Intercepting calls of separate functions using a sprx and a stub. (I will explain this using the same subroutine as previous method.)

This method is I think the easiest one. I will make it branch to a stub which will then branch to a function inside my sprx. This method has 4 arguments: r3 - r6. The first thing to do in the stub is to save these arguments and the link register.

[Register or Login to view code]

Copy this code in your plugin. This code willl replace the call on the first image to make it branch to our stub.

[Register or Login to view code]

Copy this code aswell. It will replace the nops inside your stub to make it branch to your sprx. This is done at runtime because the sprx has no fixed address.

[Register or Login to view code]

When our hook_function returns to the stub, we will then need to forward the call to the original subroutine. For me it is sub_56FA7.

[Register or Login to view code]

This is our stub. You can write it into vsh.elf and then encrypt it back to .self or just write it in asm and copy it into memory using our sprx. (You will need to calculate the size yourself)

[Register or Login to view code]

Everything is now setup. All we need to do now is write the code inside our sprx.

[Register or Login to view code]

PS: you can forward other functions calling 0x0056FA74 to the stub too.

Download: [Register or Login to view links]

METHOD 3: Intercepting every call to a function.

This method will require some hand edits but it can also be tricky sometimes. It overwrites the 4 beginning opcodes of a function (often the stack setup) to branch to our own code. This subroutine is an example of when it won't work.

I'll explain this method using this subroutine.

You will need these scripts.

[Register or Login to view code]

This is how the function you hook to should look like. The function has 5 arguments. So we will need to move those 5 arguments back to r3, r4, r5, r6 and r7 before we can return to the function we hooked. The asm is where we will do our edits.

[Register or Login to view code]

We then need to copy the 4 beginning opcodes of the function we're hooking and load the address we're branching back into CTR using r11. For me it is 0x0063983C

[Register or Login to view code]

Now add this line somewhere in your plugin to enable the hook.

[Register or Login to view code]

This is how it looks like when compiled. Using HxD we will move the opcodes generated by the compiler on top of the beginning opcodes we copied.

Decrypt your plugin to .prx and open it up using HxD. Then locate the address inside HxD by adding 0xF0 to the address in IDA. For me it is 0x1F4 + 0xF0 = 0x2E4.

Go to that address by pressing CTRL + G or Search->Goto. Cut the bytes and paste them at the right address. Also change the blr (4E 80 00 20) to bctr (4E 80 04 20). When that is done save your file, you should end up with this.

Download VS2010 Project: [Register or Login to view links]

METHOD 4: Intercepting every call to a function using a stub and a sprx.

From Flat_z: Nice reading, I've used similar methods to dump SSL premaster secrets from PS3.

Finally, below are some PlayStation 3 Application Controller PS3 POC videos from Dnawrkshp as follows:

I read this idea from somewhere and I thought it was a really cool concept. So I decided to at least try to create it for the PS3. The result isn't usable as it probably runs at 3 fps, but it is just a proof of concept.





In more detail, there is a PS3 program and a PC program. The PC program requests the controller data from the PS3 and uses that with config from the user to interact with a program (probably an emulator). Then the PC will send the current screen to the PS3 and the PS3 will display that image on the TV. At this point, the image is sent as an uncompressed png file (probably one of the problems) to the PS3.

The video shows the PC program working exclusively with VBA and a hard-coded input config. It also doesn't have support for joysticks (yet, it won't be hard).

I don't think I can take this program any farther than it is, but maybe there is someone that can. It is completely private, but if people still want it (even for just the controller capability) I can release it. If someone wants to actually work on the source I can also release the source code for everyone.

As for NetCheat (since someone will ask in this thread), I'm still taking a break from it. Given I'm pretty much the only developer, it can be very stress inducing and I don't like that. I have a few bugs to fix and then I can push the update (CCAPI 2.5, results list locking up, and probably more).

Yeah you're right. A 549 kb png converted to a 137 kb jpg. I'll definitely change it to use JPEG and post an update. Oh yeah that definitely sped it up:





Yeah then the thing I read was probably from you. Therifboy sent me a list of things that were being requested as a plugin. I saw this one and thought that it would be a lot more practical as a full on program. Thanks for the great idea.





My AV was scanning in the background which accounted for all the random lag spikes. Otherwise I can get a reasonable 15 fps or so from this. At this point beta testing could/should occur. Anyone feeling up to testing for me? Yeah this exact text was in the thing:

Run the emulator on the PC.
Video/sound transferred to the PS3 from PC
Controls from PS3 to PC.

Anyway here's the link: Download: [Register or Login to view links]

It's pretty straight forward. Important to note that HD TV's stretch the image so much that you need a high quality to see anything. Also using a cross-over cable is the best method.

I'm definitely interested in sending the PS3's frame buffer over to the PC at a good FPS. But I think it'll be delayed (displaying on PC) and simulating controller input wouldn't be possible. At least I have no idea how to do it.

Regarding AC, I'm thinking of using UDP instead of TCP since it would be faster. Though since it isn't as reliable I wonder if that could cause the PS3 to freeze from the corrupt image. Definitely worth a try though. And thanks for testing

Couldn't get UDP to work right so I gave up.

Download: [Register or Login to view links]

I've changed a few things, namely the input simulator works with Project64 and probably more emulators. Though for some reason the arrow keys don't work... So just remap the controller to use something else and you should good to go.

The source code for the PS3 app can be found here: [Register or Login to view links]

The source code for the PC app can be found here: [Register or Login to view links]





I recorded myself playing SSB64 with my capture card so you can properly see it working. Also, Link4Life.

I'm using GDI. I implemented that DX method but it seems slower than my current GDI screen capturer. Using JPEG is definitely better than BMP. The issue isn't processing power (unless you are on a really crappy computer), but net speed. A 1.8 mb file will take more time to send than compressing it down to 50kb and sending that.

I'm going to stick with TCP just because I don't have any experience with UDP. Updating the screen only when stuff changes should work but actually calculating changes and applying them is slow... So the result is around half the speed of the regular. Here is my code on the PS3; there might be something to speed it up:

[Register or Login to view code]

I'm using GDI. I implemented that DX method but it seems slower than my current GDI screen capturer.

Using JPEG is definitely better than BMP. The issue isn't processing power (unless you are on a really crappy computer), but net speed. A 1.8 mb file will take more time to send than compressing it down to 50kb and sending that.

I'm going to stick with TCP just because I don't have any experience with UDP. Updating the screen only when stuff changes should work but actually calculating changes and applying them is slow... So the result is around half the speed of the regular. Here is my code on the PS3; there might be something to speed it up:

[Register or Login to view code]

From therifboy: Getting rid of the for loop should massively improve the speed. (I did not test the code)

Also, poking one byte at a time is a waste of time. Just set alpha to be 0xFF from the pc program and poke 32 bit at once.

[Register or Login to view code]

From Dnawrkshp: The results show that the issue lies on the PC side. Calculating the difference between images is very time consuming. Otherwise this will definitely work better.

I got this off of some site. I didn't document it for some reason so I can't link it. I did the caching of the actual changes.

[Register or Login to view code]

This is all because Bitmap.GetPixel() is very slow.








Stay tuned for more PS3 Hacks and PS3 CFW news, follow us on Twitter, Facebook and be sure to drop by the PS3 Hacks and PS3 Custom Firmware Forums for the latest PlayStation 3 scene and PlayStation 4 scene updates and fresh homebrew releases!

Comments 77 Comments - Go to Forum Thread »

• Please Register at PS3News.com or Login to make comments on Site News articles.
 
#67 - Davaci - 5w ago
Davaci's Avatar
Thanks


#66 - Taitaka - 6w ago
Taitaka's Avatar
Thanks very much

#65 - harryycas1 - 6w ago
harryycas1's Avatar
Sweet thanks!

#64 - leem - 6w ago
leem's Avatar
Thanks!!!

#63 - freedom100 - 6w ago
freedom100's Avatar
thank you

 

Sponsored Links

Sponsored Links
Sponsored Links

Sponsored Links







Advertising - Affiliates - Contact Us - PS3 Downloads - PS3 Forums - Privacy Statement - Site Rules - Top - © 2015 PlayStation 3 News