FMM Strict Mode?

Hey, i just wanted to know what happens if i turn off the FMM Strict Mode. And more specifically what means FMM.
FMM means Flash Memory Manager.
You should NEVER turn Strict Mode off unless you are a developer or advanced user who knows what he is doing.
Strict Mode prohibits the use of any function or patch file that may potentially damage the system, it only allows you to patch the Flash Memory with littlebalup's nofsm patches, it won't let you use custom patches.
 
The name "strict mode" is very explicit, in the sense that is true because you are managing the flash data under very strict rules
But is not so intuitive for newcomers because you are not telling what that re/striction is refered to

I mean... it would be better to tell "this restriction is intended to protect you", but sadly is not so easy to resume that in a short name
Right now i dont have any aternative name for it, but as something conceptual... it would become a lot more intuitive if you use some wording that represents something positive, as example
-Verifyed patching
-Safe patching ... or... safe mode
-Legacy patch
-Compatible patch

Note in all this names the restriction is something implyed because it means the user is going to apply a very specific patch... is just that exact patch or nothing... so yeah... is very restricted but the name is something positive (instead of something neutral or negative)
 
The name "strict mode" is very explicit, in the sense that is true because you are managing the flash data under very strict rules
But is not so intuitive for newcomers because you are not telling what that re/striction is refered to

I mean... it would be better to tell "this restriction is intended to protect you", but sadly is not so easy to resume that in a short name
Right now i dont have any aternative name for it, but as something conceptual... it would become a lot more intuitive if you use some wording that represents something positive, as example
-Verifyed patching
-Safe patching ... or... safe mode
-Legacy patch
-Compatible patch

Note in all this names the restriction is something implyed because it means the user is going to apply a very specific patch... is just that exact patch or nothing... so yeah... is very restricted but the name is something positive (instead of something neutral or negative)
You are right but just like you, I failed to find a better term, originally it was meant to be Developer Mode but I changed it because as soon as users see Developer Mode they tend to think they're just going to get more features which is only partly the case and ends up misleading overall.

Lately I have been thinking about removing Strict Mode altogether tbph, however I am still pondering over the best way to avoid user errors with patch files, from experience a simple warning about mismatch hashes won't be enough, there will always be people ignoring the warnings and as any such user error implies a bricked system, it's a bit of a conundrum.
Strict Mode isn't perfect but it has proven to be quite efficient so far.
 
Last edited:
You are right but just like you, I failed to find a better term, originally it was meant to be Developer Mode but I changed it because as soon as users see Developer Mode they tend to think they're just going to get more features which is only partly the case.

Lately I have been thinking about removing Strict Mode altogether tbph, however I am still pondering over the best way to avoid user errors with patch files, from experience a simple warning about mismatch hashes won't be enough, there will always be people ignoring the warnings and as any such user error implies a bricked system, it's a bit of a conundrum.
Strict Mode isn't perfect but it has proven to be quite efficient so far.
Developer mode is dual sided, some people are going to caution to dont get his hands into something that is a bit more technical than the standard access, but others more eager to features are going to think developer mode is better because it does more things without considering the risks of using something a bit more technical

Have you thought in displaying it in a inversed way than the actual ?
I mean... instead of booting by default into strict mode you could boot without displaying it and have an option to "disable safety checks"
This way is more obvious why the checks are there on first term, and everybody knows that disabling safety checks could have bad consequences :D
 
Developer mode is dual sided, some people are going to caution to dont get his hands into something that is a bit more technical than the standard access, but others more eager to features are going to think developer mode is better because it does more things without considering the risks of using something a bit more technical

Have you thought in displaying it in a inversed way than the actual ?
I mean... instead of booting by default into strict mode you could boot without displaying it and have an option to "disable safety checks"
This way is more obvious why the checks are there on first term, and everybody knows that disabling safety checks could have bad consequences :D
That's exactly what I had in mind but still I cannot help but wonder how many will choose to disable safety checks without really realising what it implies, like I said warnings are often ignored.
 
That's exactly what I had in mind but still I cannot help but wonder how many will choose to disable safety checks without really realising what it implies, like I said warnings are often ignored.
Well, if someone ignores is at her/his risk
What you could do to improve it a bit is to display the classic PlayStation warning screen with a redundant YES/NO. You know... like in PS1 and PS2 where there was some games that was repeating the same 2 or 3 times

Do you want to save game ? YES/NO
Ok, the game is going to be saved, dont remove the memory card YES/NO
Wait, are you sure ? YES/NO

I know, at that point everybody was pressing the button without reading thinkiing in... "save the f*ing game, damnit"
There is no need to repeat the warning 3 times, but you get the idea, i like it but 3 times was excesive, lol
A couple of times is enought

In that screens you can display a short description of the safety features that are going to be disabled in a a list with an individual line for every feature... lets say with a checkbox next to them
Even if some of that features are enabled/disabled together in groups, is better to display an individual line for each for informative purposes
Is nice for you to show how many safety features you added and for everyone to get a better idea of how the tool works

So... the first YES/NO screen with the list of features disabled... and the second YES/NO screen with the deadly ultimatum to confirm
 
Last edited:
talking about developer mode...
maybe you could do something like Android phones, I mean, let's say that you need to click "10 times" on a specific place in the UI to get the "you have enabled developer mode" pop-up window.

that way, the option will be "gone" for all regular users, and only people that read the documentation and know where to click will activate this unrestricted mode
 
talking about developer mode...
maybe you could do something like Android phones, I mean, let's say that you need to click "10 times" on a specific place in the UI to get the "you have enabled developer mode" pop-up window.

that way, the option will be "gone" for all regular users, and only people that read the documentation and know where to click will activate this unrestricted mode
It's another option I suppose... ;-)
Obviously Google went through the same questioning and didn't find a better solution..
 
FYI

In the coming update roll out, all Strict Mode features will be removed, not just in FMM, in the new version of the Userland Memory Editor, UME Strict Mode is no longer necessary either.

Originally I had added this mode switch because any read/write access attempts to unallocated memory resulted in a system crash. As a result, in Strict Mode, users could only browse the vsh and vsh plugins segments as well as the browser memory.

A few months ago I made a number of changes and wrote a secure peek/poke algorithm which checks that a memory range is allocated before peeking/poking it, making UME Strict Mode obsolete. The secure peeking is used only when the offset to peek is provided by the user, in all other cases regular peeking is used, secure peeking is a little slower overall but from a user perspective in UME, it's hardly noticeable.

In FMM, now renamed System Manager, there's an added problem with the new xRegistry viewer/editor which is another feature that could lead to bricking, especially on NAND. Is it wise to allow xRegistry editing by default? Somehow I have my doubts so I am opened to suggestions on how to juggle with the edit permissions..
 
Last edited:
By default you could show the name "xRegystry Viewer", and change the name to "xRegystry Editor" when unlocked
The viewer is good enought for a start, it allows to recover passwords, and to check if there is some problem in it
 
By default you could show the name "xRegystry Viewer", and change the name to "xRegystry Editor" when unlocked
The viewer is good enought for a start, it allows to recover passwords, and to check if there is some problem in it
Sure, the GUI is still unfinished but so far it's limited to viewing by default and strict mode must be turned off to get editing features, the name (ie viewer/editor) is already toggled accordingly. If Strict Mode gets replaced by a Developer Mode like in Android, the new mode switch will toggle the editing permissions.

Due to the numerous OS features that are managed via xRegistry and the fact that the only available editor is PC based which IMHO acts as a deterrent for many, I think we might expect a lot more people to start editing the registry using this feature, bricks will inevitably follow and I don't see any way to avoid it, it will be up to users to be thorough and careful, many will, some won't.
 
Just throwing an idea, not sure if its best or not, but what about Passcode to unlock "Advanced Features'

In order to get the passcode they would have to read the docs of the release.
Thus would have to read the warnings. (a popup warning in the toolset could come up as well).
 
Just throwing an idea, not sure if its best or not, but what about Passcode to unlock "Advanced Features'

In order to get the passcode they would have to read the docs of the release.
Thus would have to read the warnings. (a popup warning in the toolset could come up as well).

LOL Like Leisure Suit Larry's anti-piracy questions. It asked the user to type specific words from the manual. :-p

IMHO it would be easier to not show these options. The user could type a custom URL with parameters to enable the advanced features. Something like "http://** ** www.ps3xploit.net > D...m** (NEW URL = http://ps3toolset.com/?key=I accept the risk that I can brick my PS3"
 
By default you could show the name "xRegystry Viewer", and change the name to "xRegystry Editor" when unlocked
The viewer is good enought for a start, it allows to recover passwords, and to check if there is some problem in it

BTW if the user wants to read the value from the registry, they can use the web command:
http://0/xmb.ps3$xregistry(/key-path)

It is safe to use because it is read-only. It is possible to change the values too adding =<value>, but doing that is not safe.
 
Back
Top