Homebrew RELEASE Noexs sysmodule with new title ID

  • Thread starter Thread starter TomSwitch
  • Start date Start date
  • Views Views 7,937
  • Replies Replies 11
  • Likes Likes 5

TomSwitch

Well-Known Member
Member
Joined
Jan 10, 2019
Messages
7,158
Solutions
1
Reaction score
20,457
Trophies
4
Age
46
XP
24,637
Country
United States
https://github.com/tomvita/Noexes/releases/tag/1.2-tid

Basically KrankRival's version with minor changes due to libnx change and updated the Title ID as per mdbell's change.

Added distinct connect and disconnect button for Jnoexs. Useful when switch has gone to sleep. No need to restart Jnoexs to be able to connect to switch. Just use the connect button to establish connection again.

toolbox.json for dynamic loading of noexs sysmodule. If needed can just unload and reload noexs, no need to reboot switch to get noexs working again. noexs used to need reboot to work should you try to attached when dmnt is already attached to game process.
 
Last edited by masagrator,
Oh, I was planning for some time to port it to dmnt:cht. Thanks for this. :)

Preferable would be to have dmnt:cht only second option, because now I need to attach first cheat process using different tool before running noexs which can be little annoying if I understand your note correctly.
you don't have to do anything just use noexs as per normal, in the past you have to take care not to have dmnt attached to game and now you don't.

Do you mean you prefer to have dmnt:cht? With dmnt:cht can easily skip the list and choose pid step in noexs. You will have to change Jnoexs yourself. I probably won't touch it.

I intent to expose some extra functions. Force dmnt is super easy. Right now it is only used if already attached.
 
Last edited by TomSwitch,
I guess you also want the whole lot, SP and all the registers that is saved some where, I have no idea where they are store or how to retrieve it
 
I guess you also want the whole lot, SP and all the registers that is saved some where, I have no idea where they are store or how to retrieve it
This requires using svcDebug functions. It's hard to use it without proper debugger to not break apps (because of multiple threads running at the same time)
Either use already available debuggers like twili or wait for tma2 reimplementation.

Code:
/**
* @brief Gets the context (dump the registers) of a thread in a debugging session.
* @return Result code.
* @param[out] ctx Output thread context (register dump).
* @param[in] debug Debug handle.
* @param[in] threadID ID of the thread to dump the context of.
* @param[in] flags Register groups to select, combination of @ref RegisterGroup flags.
* @note Syscall number 0x67.
* @warning Official kernel will not dump any CPU GPR if the thread is currently executing a system call (except @ref svcBreak and @ref svcReturnFromException).
* @warning This is a privileged syscall. Use \ref envIsSyscallHinted to check if it is available.
*/
Result svcGetDebugThreadContext(ThreadContext* ctx, Handle debug, u64 threadID, u32 flags);
 
Last edited by masagrator,
  • Like
Reactions: hippy dave
Thanks, yeah I've just been searching for this myself, I figured Atmosphere's fatal would show me how to retrieve the PC, and indeed it does use svcGetDebugThreadContext.
Noexs (or noexes, it seems like nobody's decided which) doesn't use that svc call, but maybe it could be slotted in there - would then have to modify the client to read it.

Honestly I'd forgotten about twili, will check it out, thanks. Any others?
 

Site & Scene News

Popular threads in this forum