Editing Talk:ReDRM / Piracy dongles
Jump to navigation
Jump to search
The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then publish the changes below to finish undoing the edit.
Latest revision | Your text | ||
Line 1: | Line 1: | ||
==Q&A== | ==Q&A== | ||
Q: Is this posible on other dongles from the FW3.41 days like Blackcat and Teensy? <br /> | Q: Is this posible on other dongles from the FW3.41 days like Blackcat and Teensy? <br /> | ||
Line 83: | Line 5: | ||
Q: Are they (TB team) just stealing the dev eboots? <br /> | Q: Are they (TB team) just stealing the dev eboots? <br /> | ||
A: You can only rumor which source they use to resign the content to lock-in their DRM. But ofcourse those very same DRM-less files can be resigned for 3.55 too (as has been done numerous times in the past). Piracy is bad, but pirates using DRM to make sure ''they'' get the money and ''not'' genuine developpers is even worse (especially when they lock you into a single firmware that has even less to offer than generic MFW and makes you loose OtherOS++ too). <br /> | A: You can only rumor which source they use to resign the content to lock-in their DRM. But ofcourse those very same DRM-less files can be resigned for 3.55 too (as has been done numerous times in the past). Piracy is bad, but pirates using DRM to make sure ''they'' get the money and ''not'' genuine developpers is even worse (especially when they lock you into a single firmware that has even less to offer than generic MFW and makes you loose OtherOS++ too). <br /> | ||
=== Files to strip === | === Files to strip === | ||
Line 447: | Line 53: | ||
`-- server_ps3.sprx | `-- server_ps3.sprx | ||
</pre> | </pre> | ||
== About USB descriptors == | == About USB descriptors == | ||
Line 472: | Line 79: | ||
Fake proof: | Fake proof: | ||
# Though the 2.3 payload upon execution does relocate itself to 0x80000000007f0000 then continue execution, the USB descriptor is still present, at minimum those 0x20 bytes would need to be removed, or accounted for during the initial execute. multiMan has no facility for this. | # Though the 2.3 payload upon execution does relocate itself to 0x80000000007f0000 then continue execution, the USB descriptor is still present, at minimum those 0x20 bytes would need to be removed, or accounted for during the initial execute. multiMan has no facility for this. | ||
# The initial EBOOT.BIN.elf does contain the 2MB flash contents for the dongle, BUT that would need to be carefully extracted (and has been, it too is available on the | # The initial EBOOT.BIN.elf does contain the 2MB flash contents for the dongle, BUT that would need to be carefully extracted (and has been, it too is available on the ps3devwiki), again multiMan has no facility for this. | ||
# The creating of the folder and copying the files into it was just to make this fake seem more real with additional steps. multiMan has no code to ever look inside that directory. | # The creating of the folder and copying the files into it was just to make this fake seem more real with additional steps. multiMan has no code to ever look inside that directory. | ||
# The fact of the matter is that the source code for multiMan was available, and there is NO provisioning in multiMan for "additional" payloads of any kind, the values possible in the .ini file are hard-coded. It is well documented what payloads work with multiMan, and multiMan will only work with those payloads. | # The fact of the matter is that the source code for multiMan was available, and there is NO provisioning in multiMan for "additional" payloads of any kind, the values possible in the .ini file are hard-coded. It is well documented what payloads work with multiMan, and multiMan will only work with those payloads. | ||
Line 479: | Line 86: | ||
http://pastie.org/private/2dnlv03jlewuyrw9g4he6w | http://pastie.org/private/2dnlv03jlewuyrw9g4he6w | ||
== old talk == | == old talk == |