Hacking [Pre-release, WIP] Yet another rxTools?

  • Thread starter Thread starter duke_srg
  • Start date Start date
  • Views Views 89,963
  • Replies Replies 659
  • Likes Likes 68
why don't you ask @d0k3 for a9lh?
Because current preview is not finished and I don't want anyone to hold with their working projects and help with this one unless it is not fully functional. So you're free to ask by yourself, but I won't for now, or it will look like I'm trying to grab the biggest piece of the pie, while I don't, just making what I can.

--------------------- MERGED ---------------------------

yes, however, the translation of the gui does not take place
Choose Русский or Español and see the main menu changes.
 
why don't you ask @d0k3 for a9lh?

Because current preview is not finished and I don't want anyone to hold with their working projects and help with this one unless it is not fully functional. So you're free to ask by yourself, but I won't for now, or it will look like I'm trying to grab the biggest piece of the pie, while I don't, just making what I can.

A9LH support is very easy, just saying. Use a Brahma compatible bin and change the framebuffers to this:
Code:
#define TOP_SCREEN0 (u8*)(*(u32*)0x23FFFE00)
#define TOP_SCREEN1 (u8*)(*(u32*)0x23FFFE00)
#define BOT_SCREEN0 (u8*)(*(u32*)0x23FFFE08)
#define BOT_SCREEN1 (u8*)(*(u32*)0x23FFFE08)
This also won't break Brahma compatibility, so you can keep the change in for Brahma as well.

For 2xrsa compatibility (browser entrypoint on 2.1) it is the same, just the framebuffer has to be changed. Only CakeHax (because of its chainloader) and GW Launcher.dat (because of whatever they do) are special and require more changes.

The D9 & OTPHelper source .s /.ld / Makefile / draw.h may help to understand this, too.
 
Last edited by d0k3,
Also, when fixing / adding / modifying entrypoints, keep in mind that one of rxTools big advantages is compatibility with lower FW versions. We did, f.e., use an older version of rxTools to recover a 2.1 N3DS without a previous backup. Cakes / ReiNAND / Luma3DS would not have helped here.
 
Because current preview is not finished and I don't want anyone to hold with their working projects and help with this one unless it is not fully functional. So you're free to ask by yourself, but I won't for now, or it will look like I'm trying to grab the biggest piece of the pie, while I don't, just making what I can.

--------------------- MERGED ---------------------------


Choose Русский or Español and see the main menu changes.

I selected the Spanish language to no avail in the gui.
I selected the Russian language and have changed only two menu items (in all gui)
the two voices that until changed:
reboot
Shoutdown
all else remains unchanged, unfortunately it does not work
 
Also, when fixing / adding / modifying entrypoints, keep in mind that one of rxTools big advantages is compatibility with lower FW versions. We did, f.e., use an older version of rxTools to recover a 2.1 N3DS without a previous backup. Cakes / ReiNAND / Luma3DS would not have helped here.
Can you make the a9lh support please?
 
  • Like
Reactions: chronoss
I selected the Spanish language to no avail in the gui.
I selected the Russian language and have changed only two menu items (in all gui)
the two voices that until changed:
reboot
Shoutdown
all else remains unchanged, unfortunately it does not work
Please understand, all english strings while printed a processed tgrough the translation routines - as soon as there are keys in corresponding lang/*.json. If you update ru.json and es.json from the latest commit, you'll see more translated strings. Translation just have to be done, and I even don't have enough time to compete my native russian translation because I have many other things to fix. If you can translate to Italian, it will be great, just remember.Ber, the only thing to change will be it.json.
 
A9LH support is very easy, just saying. Use a Brahma compatible bin and change the framebuffers to this:
Code:
#define TOP_SCREEN0 (u8*)(*(u32*)0x23FFFE00)
#define TOP_SCREEN1 (u8*)(*(u32*)0x23FFFE00)
#define BOT_SCREEN0 (u8*)(*(u32*)0x23FFFE08)
#define BOT_SCREEN1 (u8*)(*(u32*)0x23FFFE08)
This also won't break Brahma compatibility, so you can keep the change in for Brahma as well.

For 2xrsa compatibility (browser entrypoint on 2.1) it is the same, just the framebuffer has to be changed. Only CakeHax (because of its chainloader) and GW Launcher.dat (because of whatever they do) are special and require more changes.

The D9 & OTPHelper source .s /.ld / Makefile / draw.h may help to understand this, too.
Honestly, it should be too hard to port over A9LH compatibility and FIRM0/1 protection. I mean you can easily port over the source from ReiNAND/Luma3DS.
 
Can you make the a9lh support please?
@d0k3 does not do CFWs. I can help with questions such as this, though. And I'm pretty sure we have at least one (at least) beginner level programmer on here who knows how to change the framebuffers.

Honestly, it should be too hard to port over A9LH compatibility and FIRM0/1 protection. I mean you can easily port over the source from ReiNAND/Luma3DS.
Don't say something is easy unless you actually have read and know the source ;). Getting it to work will be easy, FIRM protection may be not.
 
Last edited by d0k3,
@d0k3 does not do CFWs.


Don't say something is easy unless you actually have read and know the source ;). Getting it to work will be easy, FIRM protection may be not.
Let me rephrase that, it's easier compared to when we first started. Now there actually is a reliable source to pull from, compared to when we first started.
 
Let me rephrase that, it's easier compared to when we first started. Now there actually is a reliable source to pull from, compared to when we first started.
Let me rephrase that, first Yellows8 or plutoo having a hard sex time investigating vulnerabilities, then the ant-heap is copy-pasting ;)
 
Last edited by duke_srg,
I would give this new rxtools a try, cause I'm using still the 3.0 version ^^ (fast enough for me and stable with menuhax)
So I saved my old rxTools folder, delete it and do the standard steps (new rxtools folder to sd, firm folder within it, change for test-run my boot.3dsx (ctr) to rxtools one)
It starts fine and installs fine (I think so..), but it doesn't recognize my emuNand(however)?? I can't start/dump or do anything with the emuNand options, nothing.
I am doing anything wrong, forget something?

sysNand: 9.0E, emuNand 10.3E
 
I can't start/dump or do anything with the emuNand options, nothing.
I am doing anything wrong, forget something?
NAND partitions detection is automatic now rather then from the list of predefined values before. The downside is GW-type EmuNAND with the size different from SysNAND could not be detected. Though it still could be usable being registered properly in SD card MBR, since in that case it's size taked from there, but for now it's only made automatically on boot for detected EmuNAND.
So how did you exactly initially created your EmuNAND? Could you check the dump sizes from the SysNAND and EmuNAND and check the first sector NCSD partition table?
 
Also, when fixing / adding / modifying entrypoints, keep in mind that one of rxTools big advantages is compatibility with lower FW versions. We did, f.e., use an older version of rxTools to recover a 2.1 N3DS without a previous backup. Cakes / ReiNAND / Luma3DS would not have helped here.
Do you mean 2.X which uses Roxas75's original entrypoint but not CakeHax?
 
NAND partitions detection is automatic now rather then from the list of predefined values before. The downside is GW-type EmuNAND with the size different from SysNAND could not be detected. Though it still could be usable being registered properly in SD card MBR, since in that case it's size taked from there, but for now it's only made automatically on boot for detected EmuNAND.
So how did you exactly initially created your EmuNAND? Could you check the dump sizes from the SysNAND and EmuNAND and check the first sector NCSD partition table?

Ah I understand, that's the problem. I have a GW EmuNand, because I usually create EmuNands with my GW^^.
If I swap to a RedNand, ther should be no problem so, but can GW read also this other type?
What are my options to keep an EmuNand that can read GW and this versionf of rxtools? The old/original one has no problems to read/boot them.
 
Ah I understand, that's the problem. I have a GW EmuNand, because I usually create EmuNands with my GW^^.
If I swap to a RedNand, ther should be no problem so, but can GW read also this other type?
What are my options to keep an EmuNand that can read GW and this versionf of rxtools? The old/original one has no problems to read/boot them.
Not exactly, GW EmuNAND created from your SysNAND should work fine, I have that one too. Looks like somehow your EmuNAND is of the different size of SysNAND. Could you backup both and cut only the first sectors for me to check?
 
Nice! Still use the rxtools from way ago with my o3ds as a back up. Glad that it's being re-worked!
Thank you for your dedication to the project !! All the best!
 

Site & Scene News

Popular threads in this forum