Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - dots_tb

Pages: [1] 2 3 4
oh no no no sami bran muffins, THE GIGA GIGA HOMO, still has problems with his HOMOPHOBIA!

"date" and "dog" similar? sami doesn't know how the especially works!  ahhahahahahahaha

keep trying sami sweety we know you are the big (closet) gae!  this evidence is as concrete as the big PPs you suck!

PS Vita / MOVED: [Release] Catherine Full Body HD 720p Patch
« on: May 07, 2020, 04:09:35 AM »

PS Vita / Re: [Release] Catherine Full Body HD 720p Patch
« on: May 06, 2020, 07:27:19 PM »
This a pretty neat patch, I just made an account to say thanks. Do you think this would be possible for a Persona 4 Golden 720p Patch?
Marbs (cuevavirus) said on Discord while he is not going to make anymore HD patches, he will consider making one for P4G.

The graphics are improved a lot, there's noticeable less aliasing, I wonder if using the NO ASLR plug in would increase performance? even better maybe disabling more system security checks or not essential processes would benefit running games at higher resolutions.

I think Marbs has also tried noASLR with Catherine and saw no difference, but perhaps more analysis is needed to see the difference or more work on noASLR needs to be done as it is targeted towards system applications.

PS Vita / Re: [Release] Catherine Full Body HD 720p Patch
« on: May 06, 2020, 05:50:20 AM »
This is just an attempt to steal Atlus's hardwork all you did was enable HD.

This is not only historical, but also begs the question if retail games will eventually be able to run at full HD resolutions

Probably, but I doubt it would run well. I recall it being discussed a while back, when VitaGrafix was still in its early stage.

Best we can hope for is, native resolution patch for games(960x544) and Sharpscale to 1088p.

Well that is assuming you are running HD on intensive games, there are plenty of non-intensive games that could benefit from these new resolutions that were not limited due to the processing power, but rather the display itself.

Most of the previous resolution hacks were for games that did not even utilize the full resolution capabilities of the display and that were gimped due to the devs feeling the Vita was not powerful enough.

I think the previous discussion was in relation to rendering it at a higher resolution, then downscaling it to display to create a clearer image, not sure if its actually been attempted.

EDIT: Previous discussion as in relating to VitaGrafix.

Read these / Re: Overall Rules
« on: April 25, 2020, 06:14:12 PM »
Rules were updated. Because there was a site wide notification among members to reread these, warnings may not be issued when a user is banned in breaking these rules.

Added rule: Any off-topic information not conforming to the topic set by the OP will result in a ban. Assuming that the OP has followed these rules.

PS Vita / Re: Vita Babe Of The Week
« on: April 25, 2020, 06:04:24 PM »
why is there only female pic in this post?
Please refer to global rules 2, 12. You have been warned.

Some info regarding the "Yifan Lu request". I remembered on some barren forums where Yifan said something about wanting serial over USB. It turns out my memory was almost correct:

This found after teakhanirons mentioned there was, which fit the description in my memory. However, this forums has long been purged. But luckily Coburn, of the Kantai Collection translation team, copy and pasted it. The topic was originally relating to project ideas for taihen, so not really a request per se.

Context (for people who like a story):
After working on a psp2048 port, along with a failed project with sysie, sysie decided to ask me to help with the Kantai Collection translation project. Coburn was sure that stdio would help solve the issue of xml edits not loading properly. It did not. However, that is how Shiplog was born.

Looking back at Yifan's comment it makes total sense, its a shame that the failing had deleted the actual post.

What really makes no sense is that when asked on IRC, Yifan would often say hook printf (which never worked) instead of setting a callback like he did in that post, this not done until ShipLog v2.

Now with PrincessLog and PSMLog this project idea has been fully realized.

CBPS is committed to only bringing you the facts!

When taihen was first released, it was requested by Yifan Lu to use the USB serial functions to facilitate logs. These serial functions were used by PSM and now have been made to redirect stdout to a usb serial device, which serves as a standard COM serial port.

Princess Silly Mini Log USB is Princess Log with net functions replaced with USB serial functions and was created at the request of Silica, Pina and SonicMastr. It has full compatibility with Vita Shell's USB Mass Storage device system.

  • Install PSM USB Serial Drivers. These were extracted from the PSM SDK. Get them here:
  • Add PSMLogUSB.skprx to your config.txt and reboot.
  • Open your favorite serial monitoring program and set the correct COM port. Set the baudrate to 57600.

   PSMUSBLog will try to end any other USB service, except the the one used in VitaShell for Usb Mass Storage(UMS) mounting. So this will naturally create incompatibilities with plugins such as vita-udcd-uvc.
   When using UMS, the serial will be interrupted, however will auto-start up after the UMS service has ended.

   The serial device will also be disconnected on reboot and will only restart until the plugin is re-initialized (usually right when Taihen launches)
Serial Monitoring Programs:

   You may use any serial monitor program. However, because of the constant reconnecting, I'd recommend kiTTY. <!pages/>
   This program allows easy auto reconnect (Connection > Attempt to reconnect on connection failure)
   You may also want to enable newline mode: (Terminal > Implicit CR in every LF)
   Finally, to find your COM number, look at the "Device Manager" in Windows. It will be under "Ports (COM & LPT)"
Why use PrincessLog over this:

   If you are working with USB or are using a Linux dev enviroment (have not checked if Linux has drivers), you may still want to consider PrincessLog.


Special thanks to:
Yifan Lu

Princess of Sleeping

I was watching that PSP Homebrew conference thing and thought the ME processor accelerating Minecraft from 15fps to 60fps was cool.

So I thought it'd be cool to do something similar with the Vita with the MIPS processor.

However, it seems TheFlow has achieved this ( But I'll just document this if it hasn't been documented already:

The idea was to write to the MIPS reset vector as was done in the ME example Motolegacy linked (

The reset vector should be the first thing that is executed by the processor, which before command 0x30006, is held in SceCompatSharedSram.

Normally, if you try to peak at the SceCompatSharedSram, it will cause a crash until command 0x30006 on compat_sm.self is called. However, on accident by putting the wrong amount of arguments on a hook, I found that passing 0 size on 0x10006 allows you to write to the reset vector once through some f00d glitch. Maybe I'm wrong, try for yourself.

This was tested on 3.60.

To prove this theory:
  • A hook is made set the 0x10006 command to fail with 0 size on SceCompat
  • This hook will then read "ux0:/data/mips_rst.bin" to the reset vector. I will attach the the pre-ipl + challenge mips_rst.bin to the post.
  • Adrenaline is then loaded (it seems to only work once for Adrenaline?) with the mips_rst.bin loaded into the Reset Vector.
  • Adrenaline is then loaded without  mips_rst.bin, causing error c1-2650-3
  • Adrenaline is then loaded with the continue commented out, which causes kpanic.
  • Change the hook to pass the size, and it should crash.
  • Uncomment write_reset_vector(); in the standalone func, it should crash.

I will be posting more findings relating to SceCompat if they are not already documented.

Thanks to Mathieulh for his Wiki information, Motolegacy for linking the ME example, Celesteblue and Princess of Sleeping for being fappers and helping a ton, teakhanirons, and Sysie for method of testing

TheFlow for adrenaline.

Anyways, in what has become standard for me, I just found this and have no idea how it works. Hopefully, someone will find it useful.

This post was originally made by SuperiorSpidy to /r/vitahacks, I was surprised when I went looking for it and it was missing. Luckily it was archived on removeddit and I had a link in my phone history. I am archiving it just in-case some of you have missed it:

Quote from: SuperiorSpidy
robots commented 10 hours ago • edited

So, since this corona stuff, work is being relaxed. I think i will have time to work on this.

I have created repository, and pushed all my stuff into that. I cannot push my notes there as they are in my head :-)

robots/[email protected]

Description:psp part: this is copied and reworked uofw ge driver. All writes and reads from registers have been replaced by requests to vita.

PSP ge driver is source: my additions (hopefully fixes):

Since there is limited number of shared resources between vita and psp, we have to share. There is at least one messagebox free (KERMIT_MODE_EXTRA_1, adrenaline uses KERMIT_MODE_EXTRA_2). But these are no interrupts free. We will share the interrupt adrenaline uses. Adrenaline uses this only to signal save/load of state and memory card reinsert - these are very rare interrupts, thus Adrenaline will not mind sharing.

u/NT-Bourgeois-Iridescence-Technologies it is not possible just to stream gpu data from psp. Gpu data is in ram that is not accessible from vita.

I patch the sceGeEdramGetAddr function to return address in vita's CDRAM (mapped into PSP's memory space) This way PSP game will write directly to shared memory. This makes it harder to have both gpu on vita, and ge on psp work at the same time (i would like to have switch, for games that are not yet compatible, but i am sure we can unpatch the ge driver or add some flag to select code.)In psp code i think it misses just the hooking stuff (and the flag)

For the vita part, i have started to write the GE state machine in C. I use PPSSPP's gpu framework as source of ideas. But its like 2percent of work done.

The roadmap should be something like:

write vita's ge statemachine
test it on vita only (with some psp example from
finish psp ge driver hooking.
test complete system.
So what is needed is one PSP developer who knows psp hooking stuff to finish the ge driver.




It seems that the /r/vitahacks mods have deleted it... No one is safe from them.

Reverse Engineering / Re: Bruteforcing NIDs on the PS Vita
« on: April 05, 2020, 03:11:24 AM »
I thought of something else, since the no name suffix is only used for exports without a library name, that would infer that the suffix is generated from the library name in an unknown fashion.

Reverse Engineering / Re: Bruteforcing NIDs on the PS Vita
« on: April 02, 2020, 09:23:45 PM »
Further info:
Regarding the unknown suffixes, certain properties can be discerned:

We know from modules like SceNpDrm the dbg_fingerprint (or module NID in some non-updated documentation) can change, with functions within it staying the same. Celeste has told me that this is a hash used for versioning.


The hashing algorithm for this can be found within the official SDK, however we have not confirmed if this is the same algorithm used by Sony internally. It is very likely that it is.

When a module is updated, it doesn't necessarily mean that the suffix will change. We know that certain modules with added features will maintain their NIDs for the syscalls. (Need to check for the libraries).

All Library NIDs get updated per a module, when this happens, the syscall NIDs also get updated? (Need to confirm).


Regardless, very nice work cuevavirus!

Reverse Engineering / Bruteforcing NIDs on the PS Vita
« on: April 02, 2020, 04:37:43 AM »
Some information pertaining to bruteforcing NIDs on the PS VITA:

The algorithm would fall into two categories:

Category 1: The system used on the PSP was just a sha1 hash with the first few bytes selected and then byte swapped, there are a few libraries that follow this scheme on the PSV


sha1(ScePowerForDriver) is equal to:
Code: [Select]
The library nid is the following:
Code: [Select]
So then, with a quick check, I found that the following libraries can be easily bruteforced with this method:
Code: [Select]

This means that any syscall within these libraries can be bruteforced with just sha1. Many of the names are shared with the PSP, however they have been already bruteforced.

I think there is another library called something along the lines HPRemote that can also be bruteforced, with most of the known ones being added to the henkaku wiki using this method.

I have also found that modules compiled with the official SDK also use this:

Code: [Select]
The functions nid:
Code: [Select]
Thus, every module included in official games can have their function names bruteforced as long as they actually are exported. Ex: Unity modules and the modules included with PSO2.

You CANNOT bruteforce function names that are not exported such as internal functions or any function within the main eboot. This is how the mono NIDs I had posted earlier were found.

Category 2: These NIDs have a suffix which is concatenated to the end of the name before they are hashed. The methodology of obtaining these generating these suffixes are yet to be found.

However, we do have an example of one suffix:
Code: [Select]
Found here:

This specific suffix is used in generating function NIDs for functions with no library, such as module_start:

module_start + suffix (binary data) as hex:
Code: [Select]
6D 6F 64 75 6C 65 5F 73 74 61 72 74 C1 B8 86 AF 5C 31 84 64 67 E7 BA 5E 2C FF D6 4A
Yields the results:
Code: [Select]
The actual NID is:
Code: [Select]
It is theorized that the majority of NIDs are generated using a suffix, however, again, the methodology of generating this suffix is unknown.

Special thanks to CelesteBlue and Princess of Sleeping.
Further thanks to SocraticBliss and ChendoChap for working on a hashcat bruteforcer, and SilverSpring.

Pages: [1] 2 3 4