Todo List

[Yohoki]

Things that I want to add but have not yet or don't know how.

Todo:

• Migrate from using set (old-style) input boxes to a scroll-able list for MemDump files.
  This would allow unlimited numbers of dumps/address pairs to be added.
• Add support for Pointer Searching up to 64-bit addresses and Endianess for future consoles to be added.
• Run the Pointer Searcher on a separate / multiple threads.
  The searcher runs on initial search, but also any time a pointer is opened to a new level.
  This can result in HEAPS of lag if using a macro to mass-open pointers.
  It doesn't crash to blue screen when using too much RAM afaik, but it might take all night.
• Add option to ignore non-4byte aligned offsets to reduce search time and process time.
• Add a way to import a code list and export it with the new pointers added.
• Add a "Code Viewer" for imported codes to allow easy editing of .PSV file
• Add a debugger option to view .bin files directly in app and possibly show what the codes will do when active.
• Add a way to search for pointers rooted in Seg0/Seg1 by using an offset and starting addresses.
• Add a way to add Localization options.
• Maybe an easy way to swap the language in-app
• Maybe a simple way to swap the languages out in Visual Studio to upload separate apps.
• Make locating higher accuracy pointers easier.
• Maybe auto open pointers to X levels?
• Maybe collect all Orange/Red pointers and put in new list?
• Maybe find a way to search for or scroll to orange/red pointers that are already in the list
• Read the C# code and give better names
• Some of the code has no commenting or naming after the reverse engineering of original TempAR
• It would be a LOT easier to understand the code if these things were labeled better.

In Progress:

• Add boxes for specifying Modules' Segments.
• Check Segment ranges and make a clear mark on pointers that are within seg0/1
• Automatically add b200 to autogenerated codes that fall within seg0/1

Completed:

• Add b200, Joker ($C) and conditional codes as optional additions to code gen tab.
• Find or make a better font so that 8/B and 0/D are not easy to mistake.
• Add a dropdown menu for future Code types, as adding many more will clutter the page.
• Add a new "VitaCheat" tab for generating ALL code types for VitaCheat (Write, MOV, Compress, PtrMov, etc)
• Addd more Memory Dumps for better accuracy

Anyone with C# experience is more than welcome to help out or give a pointer.

[Yohoki]

Notes:
Adding in Conditionals and ButtonPad code types is probably going to take a rework on how the ENTIRE code generation writes the generated code. It was fine for most codes, but Conditional and ButtonPad require a byte to specify how many lines it effects.

I'm going to have to either give them a text box to input how many lines to use (More customizable, but less intuitive) or make the code automatically count the lines. (Harder but requires no input from users)

I would probably like the automatic path better, because an advanced user will know how to tweak it if they need to. But it's going to require generating the code for the ButtonPad/Conditional after the rest of the codes have been generated. At the moment, all the code generation just adds on to the next line of the previous part. So, I can't have ButtonPad tacked on to the bottom, but it also has to know how many lines are in the code, so it can't be at the top.... I don't think.... I'll think on it tonight. Maybe it is possible.

[Yohoki]

NEVER MIND I'M A FREAKING BOSS!

[BullyWiiPlaza]

Hi, let me give you my feedback on TempAR just like you did on my pointer searcher.

• When I tried searching pointers with Wii U memory dumps the results were weird. I realized the problem was that the memory dumps are in big endian byte order and the pointer searcher can only deal with little endian. One idea would be to add support for specifying the endian of the memory dump(s) which would immediately allow you to support all big endian (32-bit) systems as well like the Wii or Wii U.

• I really like the fact that you can find references to the current pointer by double-clicking the pointers in the results list. However, an option to automatically find a certain depth and expand the nodes would be cool as well so it's less "manual" work of expanding. This is similar to your original TODO of Make locating higher accuracy pointers easier.

• When starting a pointer search, the whole GUI freezes. That's not good. You should run the pointer search in a different thread than the GUI so the application has a more responsive feeling.

• It looks like you cannot remove/delete a file path once it's added. Is there anything I'm overlooking? The clear button only clears the results but not the memory dumps/addresses.

• The pointer searcher finds misaligned offsets. All offsets except for the last one has to be divisible by the bit type because the platform only uses adresses aligned to the bit type:
  
  My pointer searcher does not list those results because they are badly aligned with respect to 32-bit:

• I wouldn't expect it since it's probably a major headache to implement but some platforms have multiple memory areas you should take into account. Currently, the pointer searcher only accepts a single memory dump file. This only works if all the memory is contiguous. If there are e.g. 2 different non contiguous memory areas, you cannot find pointers across all memory areas e.g. the MEM80 and MEM90 memory areas on Wii.

• Like we discussed before, restructure the GUI to support adding unlimited memory dumps. You can do this with a table/list or something like that. Adding the fields like you did right now doesn't scale to arbitrary numbers.

• Totally insane suggestion but rewriting the whole pointer searcher in C++ would probably provide superior performance if you care. However, the way it works right now, performance isn't even an issue. Alternatively you can try compiling the C# code to native code directly.

I hope you also appreciate some of this feedback just in case you feel like challenging yourself or working harder on your pointer searcher to make it the best it can be. 👍

[Yohoki]

Hi, let me give you my feedback on TempAR just like you did on my pointer searcher.

Brother, I've read it all and have some ideas in mind, and maybe a few points where I have little interest in pursuing. I haven't forgotten your app, either. I ran it the other day, but I had gotten busy doing some tutoring over the weekend, so I haven't gotten back with you yet.

I'd also like to mention that I've just the other day managed to write a "Hello, World!" to console all by myself... Yes, I know, that's completely backwards and I should have learned that BEFORE I took on a pointer searcher project! XD So, many of these ideas are things I'd LIKE to add, but have no idea where to even start. But, this has become more of a pet project than anything else, and I'll probably be adding in features as I learn new things, and re-read the entire code as I learn how c# works so that I can REALLY get to know it... because the last time I touched this program's code, I didn't even know what a function was.

That being said, a lot of what you've put here is probably a simple thing to add. Some of it I know I can already add, others I know should be easy to implement once I learn to do them. Only a few of them I think would require significant changes.

* [ ]  When I tried searching pointers with Wii U memory dumps the results were weird. I realized the problem was that the memory dumps are in big endian byte order and the pointer searcher can only deal with little endian. One idea would be to **add support for specifying the endian of the memory dump(s)** which would immediately allow you to support all big endian (32-bit) systems as well like the Wii or Wii U.

Whoops. I actually responded to this one later on. I actually had big endian and 64bit capability added in a while back in a test build... but I never pushed it because I was working on a different project at the time... mainly adding in the multiple dumps and color "Upgrading".

* [ ]  I really like the fact that you can find references to the current pointer by double-clicking the pointers in the results list. However, **an option to automatically find a certain depth and expand the nodes** would be cool as well so it's less "manual" work of expanding. This is similar to your original TODO of `Make locating higher accuracy pointers easier.`

This is a big one, and the main reason why I stopped trying to get people on the vita scene from using my tool, to using yours. Adding in the color coding REALLY helped us find pointers quicker than before, but when yours works, it works instantly and gives only a couple valid pointers. This project is now more of a learning tool than an actual hacking tool, imo. I mean, plus after the drama on the scene, I really have no motivation to help them.

* [ ]  When starting a pointer search, the whole GUI freezes. That's not good. **You should run the pointer search in a different thread than the GUI** so the application has a more responsive feeling.

Unfortunately it's not just the initial scan that freezes. Pressing space to open a level deeper also lags a lot. Especially when you get into multiple levels deep or are using 2000+ offset ranges. I am aware that this is an option, but only vaguely understand how to use threads. Will definitely come back to this.

* [ ]  **It looks like you cannot remove/delete a file path once it's added**. Is there anything I'm overlooking? The clear button only clears the results but not the memory dumps/addresses.

heh.... ya........... about that......... It's def a feature that's carried over from the original code. Some one should really get around to doing something about that..... XD

* [ ]  **The pointer searcher finds misaligned offsets**. All offsets except for the last one has to be divisible by the bit type because the platform only uses adresses aligned to the bit type:
  ![image](https://user-images.githubusercontent.com/7620135/110548537-0314af80-8131-11eb-8640-c78464702dbe.png)
  [My pointer searcher](https://github.com/BullyWiiPlaza/Universal-Pointer-Searcher-Engine) does not list those results because they are badly aligned with respect to 32-bit:

I could add a switch to ignore these on searching... That should make it quite a bit faster since it's skipping several addresses per dump... But I can't take it out completely I don't think. I would have to look at some of the codes I've made and see, but IIRC the addresses have to be 4byte aligned on Vita, but I'm pretty sure the Place the address points to can be 2byte aligned, so long as the offset ends it at a 4th byte. But, I will have to do some research there.

* [ ]  I wouldn't expect it since it's probably a major headache to implement but some platforms have multiple memory areas you should take into account. **Currently, the pointer searcher only accepts a single memory dump file**. This only works if all the memory is contiguous. If there are e.g. 2 different non contiguous memory areas, you cannot find pointers across all memory areas e.g. the MEM80 and MEM90 memory areas on Wii.

I'm pretty sure this will require some heavy tinkering. To be fair, the original creator MAINLY made this for NDS and PSP, and we only adopted it into the vita scene after we saw it mostly worked. The only reason it supports Vita now is because the scene needed something better, and it was what they were used to. My goal wasn't to add more consoles, and it's so clunky that I probably won't... But, I also have been using this as practice to learn coding (I literally started working on this knowing 0 c# )... so if I get a better understanding of it, this may be something I add. I did have some PoC tests early on where I had it working for The Switch's x64 Big Endian dumps, but I was told they don't actually make dumps on them.

* [ ]  Like we discussed before, **restructure the GUI to support adding unlimited memory dumps**. You can do this with a table/list or something like that. Adding the fields like you did right now doesn't scale to arbitrary numbers.

I am working on a "grocery list" app right now as practice and it utilizes tables quite heavily. When I can figure out how to get that working good, that's something I can definitely add to this. But, at the moment it's beyond my scope. I have it working flawlessly on a console app, but moving it to GUI is proving troublesome. XD

I hope you also appreciate some of this feedback just in case you feel like challenging yourself or working harder on your pointer searcher to make it the best it can be. 👍

I certainly do! Actually, after talking to you about yours, I ended up studying c# a bit and made my first Main(). So, I may go back to this a bit and edit it up now that I somewhat understand what

[Yohoki]

Since my absence in the scene Princess-of-Sleeping has released a noASLR plugin, vitacheat has a new fix for an issue long plaguing the scene. Now that we have a name for the specific type of memory management, and a fix for it, we can pointer search more efficiently.

The most important of things is that regardless of games using pointers, those pointers always, ALWAYS, have a hardcoded base address somewhere in the modules' segments. Either seg0 or seg1. NoASLR makes those segments static, meaning that pointer searchers can now properly locate pointers within them. Since Vitacheat allows for using a segment's starting address as an offset, via the b200 codes, it's important to find these rooted pointers.

I have made a goal now to update TempAR with this new information. I want to make b200 codes the standard from now on, as they will work for users even if noASLR is not installed. With that in mind, I have added a couple new goals.

1. Firstly, I'd like to add a section to add the first dump's Segment locations and ranges. It's only important for dump 1, since it's the base address from which all pointers are checked. It won't matter for the others. whether noASLR is used or not, it will only affect the first dump anyway. That's just how this searcher is coded and I'm not changing it.

2. Secondly, I'd like to add a function during the displaying of codes to clearly highlight the pointers that are inside the segments. Maybe making text bold, maybe adding a border, underline or background color. Something that is easy to see and clear that it is desirable.

3. Lastly, I'd like the rooted pointers to be automatically converted to b200 codes by default. There's no reason we shouldn't be using a b200 code and a million reasons why we should be. I probably add a tick somewhere to turn off the b200 addition, for those rare occasions where it would break codes (such as in the case of MOV codes which are bugged in the z06 version of vitacheat and will probably never be fixed.

With those changes in the works, I have a feeling this will be my last update to the program. I've been out of the scene for a long time and will probably not be coming back. But, I would like to add a final contribution before leaving again. And since I randomly happened upon the noASLR plugin, this looks like a good time to drop an update and change the scene again.