I dunno whether esc0 will update those legacy files, you will have to ask him.
In any case, the PS3 Toolset update that's going to roll out over the weekend offers new patching features in the Memory Manager, you will able to easily apply/unapply the HAN or the Debug PKG patches directly from the OFW browser.
I understand, so I'll try to contact him, and see if he'll be able to update han.
thanks for the reply bguerville
Gledson
Member
I use HAN, and I prefer this one too. I've been using it since HFW 4.85.1 because I still play online without fear of being banned. I hope they update, I'm waiting for someone kind to do this for us :/
@esc0rtd3w any chance ?
Thank you for your great support
Enviado de meu Moto G Play usando o Tapatalk
Thank you for your great support
Enviado de meu Moto G Play usando o Tapatalk
atreyu187
Loathsome Dung Eater
Um you do realize folks have been banned using HAN right? The only safe way is no hacks at all. Got a 3000 unit banned using HAN.
Gledson
Member
I've never seen a person who used or uses HAN say they were banned. I've been using it since 4.85, I've always played online and I've never been banned and I've never had any kind of problem. It's even kind of strange to say that a person was banned for using HAN, since it is much more limited than HEN. Now every week I see people complain about being banned or having problems like crashes or bugs for using HEN.
esc0rtd3w
Developer
i just tested HAN.
There are a couple scenarios.
Using all the same files from 4.84-4.88 causes the standard visual problems seen on 4.89, from using the DEX explore_plugin.sprx are there, but package manager works.
Using the explore_plugin.sprx from 4.89 CEX fixes the visual artifacts, but the package manager will no longer work properly.
Adding the external HEN package manager has the same effect, the package manager is broken with CEX sprx.
There is currently no workaround to get package manager working and no visual artifacts, without having a 4.89 DEX file.
There is no current way to release an official 4.89 version that is 100% working.
HAN will probably be discontinued until a 4.89+ DEX PUP is available.
There are a couple scenarios.
Using all the same files from 4.84-4.88 causes the standard visual problems seen on 4.89, from using the DEX explore_plugin.sprx are there, but package manager works.
Using the explore_plugin.sprx from 4.89 CEX fixes the visual artifacts, but the package manager will no longer work properly.
Adding the external HEN package manager has the same effect, the package manager is broken with CEX sprx.
There is currently no workaround to get package manager working and no visual artifacts, without having a 4.89 DEX file.
There is no current way to release an official 4.89 version that is 100% working.
HAN will probably be discontinued until a 4.89+ DEX PUP is available.
IF the PKG manager you made for HEN works fine (installs official pkgs) and looks good on HFW 4.89 with HEN disabled, then in theory I see no reason why it should not work on HFW with HAN and/or Debug pkg, you may need to deploy an extra file, different sprx, modded rco, whatever gets deployed on HEN to make it work properly.
As to whether or not to discontinue, well it's up to you, maybe if you do other people will be compelled to take the job on if they wish to keep using it, it might not be such a bad thing and more time freed for other things although I must admit, updates don't come too often anymore, but still you can always count on s#ny to f#ck things up and inadvertently give you more work than you bargained for. lol
And alternatively there's always the coming PS3 Toolset update, well for all those with Internet connections anyway, no need for HFW, the new memory patching features cover both Han and debug PKG patches toggling at the press of a button as well as the possibility to use custom patch files.
And the file manager allows users to deploy their own files freely so installing the PKG manager is covered too (in the event that it can be made to work ok of course).
If ever it doesn't, I am thinking of testing a PKG install feature in the Toolset file manager anyway so there might still be hope there too.
The only obstacle I foresee is that the browser conflicts with the PKG installation, I realized that back when I wrote the wMM PKG handler snippet, the 2 sprx modules cannot coexist without crashing the system. I vaguely recall some mention of this in the official SDK, it's officially a conflict, probably shared resources without multithreaded support, the browser hugs all the memory too, I never really looked if there was something we could do to force the coexistence without crash, like surrendering some browser memory to the PKG installer or whatever..
On its own, running code to launch a PKG installation from the Toolset is trivial but it would imply that the Toolset "shuts itself down" and closes the browser after launching an external thread which will let the PKG installation finish, start another PKG installation if relevant for multiple installations and finally, according to user choice, exit or reopen the browser with the Toolset URL for reloading..
Not at all ideal but better than nothing I suppose.
We should soon be done with the current HEN/Cobra work, the next job on my list is the Toolset update release..
As to whether or not to discontinue, well it's up to you, maybe if you do other people will be compelled to take the job on if they wish to keep using it, it might not be such a bad thing and more time freed for other things although I must admit, updates don't come too often anymore, but still you can always count on s#ny to f#ck things up and inadvertently give you more work than you bargained for. lol
And alternatively there's always the coming PS3 Toolset update, well for all those with Internet connections anyway, no need for HFW, the new memory patching features cover both Han and debug PKG patches toggling at the press of a button as well as the possibility to use custom patch files.
And the file manager allows users to deploy their own files freely so installing the PKG manager is covered too (in the event that it can be made to work ok of course).
If ever it doesn't, I am thinking of testing a PKG install feature in the Toolset file manager anyway so there might still be hope there too.
The only obstacle I foresee is that the browser conflicts with the PKG installation, I realized that back when I wrote the wMM PKG handler snippet, the 2 sprx modules cannot coexist without crashing the system. I vaguely recall some mention of this in the official SDK, it's officially a conflict, probably shared resources without multithreaded support, the browser hugs all the memory too, I never really looked if there was something we could do to force the coexistence without crash, like surrendering some browser memory to the PKG installer or whatever..
On its own, running code to launch a PKG installation from the Toolset is trivial but it would imply that the Toolset "shuts itself down" and closes the browser after launching an external thread which will let the PKG installation finish, start another PKG installation if relevant for multiple installations and finally, according to user choice, exit or reopen the browser with the Toolset URL for reloading..
Not at all ideal but better than nothing I suppose.
We should soon be done with the current HEN/Cobra work, the next job on my list is the Toolset update release..
Last edited:
sandungas
Developer
There is a way to fix the graphic problems caused by the old DEX explore_plugin.sprx in 4.89 but i consider is a "dirty fix" because it have a payback. I was talking abut it some days ago, but let me make a resume to see what i mean
The problem is the old .sprx (lower than 4.89) was loading some values from some specific line number of the layout.txt files (lets say is trying to load 2 values located at line 3000 and 3001)
In 4.89 sony created a displacement (of +7 lines) in the layout.txt files so now the old .sprx (lower than 4.89) have the correct values located at line 30007 and 3008... but is still trying to load the values from lines 3000 and 3001 (that belongs to something else, the displacement of +7 made that soemthing else to move onto lines 3000 and 3001)
Now the dilemma is... we could patch in the .sprx the values that indicates lines 3000 and 30001 to increase them in +7 units (to make them match with the layout.txt files from 4.89)... but in HEN/HAN we cant patch sprx files right ? (it should work in CFW though)
In other words, there is an incompatibily in between explore_plugin.sprx and the layout.txt files... and we cant patch explore_plugin.sprx so the only other alternative is to patch the layout.txt files
But this have a payback because by doing this we would be patching the values loaded by "something else" (the positions and sizes of another XMB object)... and we dont really know what thats object
To be clear and explicit, using the examples above, in 4.88 was something like this:
line 2993 value 1888
line 2994 value 67
line 2995 value 450
line 2996 value 78
line 2997 value 23
line 2998 value 1456
line 2999 value 12
line 3000 value 120 <--- the old explore_plugin.sprx was loading the value 120 from line 3000
line 3001 value 110 <--- the old explore_plugin.sprx was loading the value 110 from line 3001
In 4.89 they added the displacement of +7 in the layout.txt files and the result is something like...
line 3000 value 1888 <--- the old explore_plugin.sprx is trying to load the value 120 from line 3000... but it loads a 1888 instead (error)
line 3001 value 67 <--- the old explore_plugin.sprx is trying to load the value 110 from line 3001... but it loads a 67 instead (error)
line 3002 value 450
line 3003 value 78
line 3004 value 23
line 3005 value 1456
line 3006 value 12
line 3007 value 120 <--- this value belongs to explore_plugin.sprx but is not loaded by any XMB object if you use the old explore_plugin.sprx
line 3008 value 110 <--- this value belongs to explore_plugin.sprx but is not loaded by any XMB object if you use the old explore_plugin.sprx
So... the (dirty) solution im suggesting is to do this:
line 3000 value 120 <--- the old explore_plugin.sprx can load the value 120 from line 3000 (fixed)
line 3001 value 110 <--- the old explore_plugin.sprx can load the value 110 from line 3001 (fixed)
line 3002 value 450
line 3003 value 78
line 3004 value 23
line 3005 value 1456
line 3006 value 12
line 3007 value 120 <--- this value belongs to explore_plugin.sprx but is not loaded by any XMB object if you use the old explore_plugin.sprx
line 3008 value 110 <--- this value belongs to explore_plugin.sprx but is not loaded by any XMB object if you use the old explore_plugin.sprx
As you can see in this example the value 1888 and 67 doesnt exists anymore... but there is "something else" that is going to try to load them... so the thin line that separates this from being a "good idea" or a "bad idea" depends completly of what that "something else"
If is just a XMB object of something tiny that appears in a rare submenu (lets say, something related with CCDA audio, MP3 players, printers, or other stuff not used by many people) then is worthy... otherway if the "something else" is something critical that is going to look broken at all times then is not worthy
All this is easyer to tell than doing it, the fact is required some research and experiments to identify how many "broken connections" with the layout.txt files there are in explore_plugin.sprx
In the examples i been using along this post i just considered there are 2 broken values, but probably are a few more (dunno, the last time i was trying to count them by looking at the XMB screenshots posted by other people i counted 6 or 8)
The other day i was looking at how this references to the layout.txt files are stored in the .sprx files and i used a few guinea pigs (eula_hcopy_plugin.sprx, eula_cddb_plugin.sprx, eula_net_plugin.sprx), and it was very straightforward because the only values that differs in between 4.88 and 4.89 are this references to the layout.txt files im talking about
https://www.psdevwiki.com/ps3/Talk:XMB_Layouts#XMB_layout_references_inside_SPRX_files
Eventually i tryed to do the same with explore_plugin.sprx but the amount of differences was huge... in other words i was not able to identify them :/
Last edited:
esc0rtd3w
Developer
we can and do patch sprx files in HEN, but for HAN i think this is still possible, but its been so long since ive tested it, it would need confirmed. I know we patch the vsh, and i think we can patch sprx in memory (at least while loaded) also. @bguerville can probably clear that up lol.
esc0rtd3w
Developer
i thought the same, but from my many variations of tests, including trying the updated external pkg manager from HEN, it still didnt work properly for me, even after enabling HAN and dbg pkgs. The refresh swirly icon stuck for Standard Packages, and no packages appeared in system. The only way i got it to work again was swapping sprx with dex one.
I dont understand why it works on HEN but not HAN, unless im missing something obvious lol
What we can do is patch data segments so if the values to patch are in data segments we could potentially patch them.
It also depends on which binary's data segment they are located, VSH is always loaded so we can easily patch that one but sprx can be problematic, some open and close, patches would get deleted in the process, others are loaded constantly, they can be patched...
It also depends on which binary's data segment they are located, VSH is always loaded so we can easily patch that one but sprx can be problematic, some open and close, patches would get deleted in the process, others are loaded constantly, they can be patched...
Like I told you, test on a HEN console with HEN disabled, see how the PKG manager fares before and after applying debug PKG patch, but don't deploy any HAN support files, the easiest would probably be not to use the Han exploit pages as Iirc they deploy files too and you don't want that for this test, you should probably use the Toolset test page to apply the patches instead.
esc0rtd3w
Developer
ill try testing it again. I can use toolset or enabler/dbg pkg files. The HAN files does have a separate installer for deploying files, and an enabler if you recall
EDIT: i just remembered that HEN has swirly icon on Standard also while disabled, so thats why we were hiding it for next release (unless refresh can be done properly to use PSN/Full pkg manager toggle). Im testing HAN stuff now.
EDIT2: so i guess the actual problem is that i cant click the Standard, even when HAN enabled and dbgpkg enabled.
Last edited:
I really wasn't expecting that I was going to get many answers in this thread, thanks for the effort of trying to update han.ill try testing it again. I can use toolset or enabler/dbg pkg files. The HAN files does have a separate installer for deploying files, and an enabler if you recall
EDIT: i just remembered that HEN has swirly icon on Standard also while disabled, so thats why we were hiding it for next release (unless refresh can be done properly to use PSN/Full pkg manager toggle). Im testing HAN stuff now.
EDIT2: so i guess the actual problem is that i cant click the Standard, even when HAN enabled and dbgpkg enabled.
View attachment 37594
but I see that this time it will be very difficult to happen, so I think it's better to accept that and start using hen.
arcadekidflo
Member
So, the problem is the visual artifacts when adding the package manager ? But what about this page strictly, would it work ? http://ps3xploit.me/hfw/han/han_enabler.html
If it was really important, for example if package manager would not work at all on HEN as well, we can always use the PKG Linker method, that will probably always work as long as we can enable HAN and debug pkgs.ill try testing it again. I can use toolset or enabler/dbg pkg files. The HAN files does have a separate installer for deploying files, and an enabler if you recall
EDIT: i just remembered that HEN has swirly icon on Standard also while disabled, so thats why we were hiding it for next release (unless refresh can be done properly to use PSN/Full pkg manager toggle). Im testing HAN stuff now.
EDIT2: so i guess the actual problem is that i cant click the Standard, even when HAN enabled and dbgpkg enabled.
View attachment 37594
I guess if anyone really wants to keep using HAN they can probably use PKG linker on 4.89 too.
Similar threads
-
PS3 Any plans to update HAN Toolbox due to tools being outdated on browser?
- Started by RoboKing's Cosmos
- Replies: 2
-
PS3 [HAN] etHANol v3.1.0 Updated for 4.93- Started by esc0rtd3w
- Replies: 4
-
-