ploggy
-
Posts
67 -
Joined
-
Last visited
-
Days Won
1
Content Type
Profiles
Events
Forums
Blogs
Downloads
Posts posted by ploggy
-
-
Ah, maybe that's where I was going wrong, I wasn't setting Enable Framskip.
Thanks for the tip.
-
Saw this on another site, it is a brilliant rom hack but it doesnt play well on surreal 64 CE. Do you know what the best settings are for Surreal?
Would love to play this on the Xbox
-
I think a little patience will go a long way. Give it a couple weeks and we may have a software solution, it all depends on how well the dongle is made.
-
QUOTE FROM PS3CRUNCH
Uncharted 3 now 100% working on v3.55 CFW consoles
First, we have to clearly give thanks to a PS3 developer that wishes to remain 'uncredited' for making available an v1.00 eboot that loaded and booted Uncharted 3 for v3.55 CFW users.
Second, there was some inital problems in getting the game to be fully playable all the way thru, but now thanks to more 'uncredited' sources, the following 26.8mb fix has been released into the wild on the 'net and it allows the game now to be fully working on both external and internal HDD's.
One good leak deserves another. Here's the 100% working fix to Uncharted 3! (for KMEAW 3.55 CFW)Follow these steps IN ORDER:
(1) Extract all .psarc's into the folder they are already in and then delete them on your HDD.
When you're done it should look like this:
..\USRDIR\build\actor33\
..\USRDIR\build\bin\dc1\
..\USRDIR\build\misc1\
..\USRDIR\build\movies1\
..\USRDIR\build\pak23\
..\USRDIR\build\text1\
..\USRDIR\build\vtex1\
(2) Now, merge included USRDIR folder with the existing one where you extracted your psarcs. OVERWRITE all files when prompted.
(3) Replace the EBOOT.BIN with the one included.
(4) Transfer to your PS3, launch in Multiman.
(5) PROFIT.
100% WORKING FIX
- No Freezing
- Journal Works
- F##k you Bat420 and moogie
I wont post the fix links incase they are not allowed here.
If anyone has problems following the NFO alot more info can be found through the link above
-
I thought I'd update you on recent events regarding this new Dongle..
It turns out you no longer need the "special" Bluray Disc's anymore or ANY discs for that matter, Now games will be playable from the HDD!!
There's also a list of all the currently compatible games which you can see from the source link in the first post.
-
QUOTE FROM PS3CRUNCH
Whom would have thought that just about a year after the first PS Jailbreak was announced for the PS3, that a year later the same thing would happen again, a new dongle would appear that would allow Sony PS3 owners to once again Jailbreak their consoles and enjoy the world of 'homebrew' and 'emulators' and 'OtherOS++' while at the same time still allowing them to play the latest games designed for v3.60+ consoles, even tho if Jailbreak'ers are still using an earlier v3.55 firmware!
Their been alot of 'mis-information' and 'rumors' floating around since the news of JB2 broke first on Indonesia forum site where the dongle was spotted for sale and working in small 'mod-shops', and then later we confirmed the 'rumors' to be true after making direct contact with one of our trusted sponsors whom had some advanced details on the device. Here is one of the first JB2 videos which was originally made by Indonesia forum member, showing the boot-up of v3.55 console and then the playing of Blu-Ray disc with a newer game title which normally would not be possible on v3.55 console due to the fact Sony has signed all Eboot's with newer encryption keys, you can also see from the video that 'RogerO' backup manager is installed, and other options showing that 'homebrew' is also possible with the JB2 dongle running:
NEWS UPDATE: October 26th, 2011 -- More exclusive PS3 news just in to our Crunching desk for all of our loyal members and followers!
The actual name of the JB2 dongle has now been announced along with official confirmed features and specs:
Welcome to the era of 'True Blue' for your PS3 which enables all your Jailbreak dreams and needs!
'True Blue' features:
Booting of games from v3.6+ (up to v3.73) from special BD-R discs available from official resellers
Runs games up to v3.56 from HDD in conjunction with 'backup managers'
Does not require the Power/Eject trick
Custom v3.55 Dongle firmware behaves like OFW when 'True Blue' is not inserted
Manufactured from highest grade components and Actel based
Durable and high quality metal case design
Tough and durable plastic packaging
Further features to be added as they are developed
On board 2 MBytes SPI flash
Supports Fat and Slim consoles currently running any firmware up to v3.55
And any PS3 which can be downgraded from v3.6+ to v3.55 (NOTE: Requires other tools, 'True Blue' currently can't downgrade a Console)
Supports all regions of consoles
Supports all regions of ISO’s to be released
Rock solid crystal oscillator on board for flawless timing
The 'True Blue' dongle allows booting of the latest the ISO’s (3.6+) from special BD-R discs which can be purchased from all official resellers.
The discs can be burned by any BD-R recorder and there are no special requirements on either PC or BD burner types.
Whilst we can disclose that the discs are specially manufactured to allow booting of the latest ISO’s, further technical information on the way by which the BD-R discs can allow booting cannot be provided, for obvious reasons.
UPDATE: -- Clearer note on the above info, in regard to questions being asked!
The special BD-R discs being SOLD are BLANK, they are not 'warez' in some cases less shady 'modshops' operating in countrys like Asia were local law enforcement turn a blind eye to 'flea market' operators they may infact FILL the disc with 'information' turning the blank disc into 'warez', but that is not fault of the 'True Blue' designers, and those places will NOT be official resellers. -- Information and pricing and list of 'official resellers' will be forcoming in new news post later this week once details are confirmed.
Second, there is alot more 'games' working then the 5 listed in the forums and emails from the original JB2 rumors, and the full list of all the tested games will be published once it is official and confirmed by us, don't trust other sources of information there alot of people out there trolling and passing around mis-information still for various reasons.
Third, even tho there is effort to 'crack' this dongle already even tho it is not in the actual hands of any of the people posting information about it, there is alot of stuff unknown about how and why it works and for many reasons we can't give further technical information but there is 'KEY' reason why you have to buy special BLANK BD-R discs, due to some background research on the Blu-Ray specs. and maybe you understand why this is only way to get your dreams filled on running the latest v3.60+ games on your PS3 correctly!
We will continue to update this Crunching news posting with real actual confirmed facts regarding the 'True Blue' dongle, as we get them.
Thanks for all your patience and loyal support, and bearing with us as we had to move servers to handle the increase traffic-load from this hot ground-breaking news story!
-
Quote from PS3HAX
How to dump the PS3 Per Console Key ReleasedJust good news after good news for the PS3 scene recently, as the folks over at PS3DevWiki have documented and released on how to dump the PS3 per console keys! For the newb what this does is basically replace the current function JB2 aka TrueBlue! In short once the keys for per_console_key_0 are found, it will basically fully unlocks the PS3 and grant as CFW access on basically ALL firmwares! This is great news for everyone in the PS3 scene and is only a matter of time before we have the keys!
For anyone with a CFW PS3 this is a must read. This maybe (as the title says) Some Potentially Massive News For CFW Users
-
WOW, just wow. Rayman runs flawlessly. Had to change a few settings (frame skip off, use no filter and use a bios) but it's amazing how well it plays, really good job guys.
I have noticed an issue tho, in Rayman when I finish a level the games sfx and music goes quiet until I turn the sound back up with the right analogue stick.
(it's not really an issue more of a niggle)
Again Thanks.
-
ATM PS2 backups doesn't work with this method
but who knows in the future it maybe possible. -
Disc Based Backups can now be run on a jailbroken PS3 via the newest version of MultiMAN.
All you have to do is burn your backup to a blank CD, pop it in your PS3, load the latest MultiMAN and load the backup from the Games tab.
Alot more in detail information can be found here PS3 HAX or here PS3Crunch
NOTE: you must create Memory Cards first for saves to work (only needs to be done once)
Again, more detailed info can be found in both the links.
Have Fun.
-
You can get Replacement Buttons from here
-
There is work being done on Mame for 360 and while I don't know what version the guy is porting, chances are it would run ALOT better on 360 than it does on Xbox.
-
GliGli released a new hack to boot the Xbox360 into XeLL and thus run homebrew software on your console. It's is compatible with ALL dashboard version and ALL Slim and Fat (expect Xenon, Falcon support will follow later) models and is unpatchable via software updates by Microsoft.
From the readme/nfo:
Introduction / some important facts===================================
tmbinc said it himself, software based approaches of running unsigned code on the 360 mostly don't work, it was designed to be secure from a software point of view.
The processor starts running code from ROM (1bl) , which then starts loading a RSA signed and RC4 crypted piece of code from NAND (CB).
CB then initialises the processor security engine, its task will be to do real time encryption and hash check of physical DRAM memory. From what we found, it's using AES128 for crypto and strong (Toeplitz ?) hashing. The crypto is different each boot because it is seeded at least from:
- A hash of the entire fuseset.
- The timebase counter value.
- A truly random value that comes from the hardware random number generator the processor embeds. on fats, that RNG could be electronically deactivated, but there's a check for "apparent randomness" (merely a count of 1 bits) in CB, it just waits for a seemingly proper random number.
CB can then run some kind of simple bytecode based software engine whose task will mainly be to initialise DRAM, CB can then load the next bootloader (CD) from NAND into it, and run it.
Basically, CD will load a base kernel from NAND, patch it and run it.
That kernel contains a small privileged piece of code (hypervisor), when the console runs, this is the only code that would have enough rights to run unsigned code.
In kernel versions 4532/4548, a critical flaw in it appeared, and all known 360 hacks needed to run one of those kernels and exploit that flaw to run unsigned code.
On current 360s, CD contains a hash of those 2 kernels and will stop the boot process if you try to load them.
The hypervisor is a relatively small piece of code to check for flaws and apparently no newer ones has any flaws that could allow running unsigned code.
On the other hand, tmbinc said the 360 wasn't designed to withstand certain hardware attacks such as the timing attack and "glitching".
Glitching here is basically the process of triggering processor bugs by electronical means.
This is the way we used to be able to run unsigned code.
The reset glitch in a few words
===============================
We found that by sending a tiny reset pulse to the processor while it is slowed down does not reset it but instead changes the way the code runs, it seems it's very efficient at making bootloaders memcmp functions always return "no differences". memcmp is often used to check the next bootloader SHA hash against a stored one, allowing it to run if they are the same. So we can put a bootloader that would fail hash check in NAND, glitch the previous one and that bootloader will run, allowing almost any code to run.
Details for the fat hack
========================
On fats, the bootloader we glitch is CB, so we can run the CD we want.
cjak found that by asserting the CPU_PLL_BYPASS signal, the CPU clock is slowed down a lot, there's a test point on the motherboard that's a fraction of CPU speed, it's 200Mhz when the dash runs, 66.6Mhz when the console boots, and 520Khz when that signal is asserted.
So it goes like that:
- We assert CPU_PLL_BYPASS around POST code 36 (hex).
- We wait for POST 39 start (POST 39 is the memcmp between stored hash and image hash), and start a counter.
- When that counter has reached a precise value (it's often around 62% of entire POST 39 length), we send a 100ns pulse on CPU_RESET.
- We wait some time and then we deassert CPU_PLL_BYPASS.
- The cpu speed goes back to normal, and with a bit of luck, instead of getting POST error AD, the boot process continues and CB runs our custom CD.
The NAND contains a zero-paired CB, our payload in a custom CD, and a modified SMC image.
A glitch being unreliable by nature, we use a modified SMC image that reboots infinitely (ie stock images reboot 5 times and then go RROD) until the console has booted properly.
In most cases, the glitch succeeds in less than 30 seconds from power on that way.
Details for the slim hack
=========================
The bootloader we glitch is CB_A, so we can run the CB_B we want.
On slims, we weren't able to find a motherboard track for CPU_PLL_BYPASS.
Our first idea was to remove the 27Mhz master 360 crystal and generate our own clock instead but it was a difficult modification and it didn't yield good results.
We then looked for other ways to slow the CPU clock down and found that the HANA chip had configurable PLL registers for the 100Mhz clock that feeds CPU and GPU differential pairs.
Apparently those registers are written by the SMC through an I2C bus.
I2C bus can be freely accessed, it's even available on a header (J2C3).
So the HANA chip will now become our weapon of choice to slow the CPU down (sorry tmbinc, you can't always be right, it isn't boring and it does sit on an interesting bus
So it goes like that:
- We send an i2c command to the HANA to slow down the CPU at POST code D8 .
- We wait for POST DA start (POST DA is the memcmp between stored hash and image hash), and start a counter.
- When that counter has reached a precise value, we send a 20ns pulse on CPU_RESET.
- We wait some time and then we send an i2c command to the HANA to restore regular CPU clock.
- The cpu speed goes back to normal, and with a bit of luck, instead of getting POST error F2, the boot process continues and CB_A runs our custom CB_B.
When CB_B starts, DRAM isn't initialised so we chose to only apply a few patches to it so that it can run any CD, the patches are:
- Always activate zero-paired mode, so that we can use a modified SMC image.
- Don't decrypt CD, instead expect a plaintext CD in NAND.
- Don't stop the boot process if CD hash isn't good.
CB_B is RC4 crypted, the key comes from the CPU key, so how do we patch CB_B without knowing the CPU key?
RC4 is basically:
crypted = plaintext xor pseudo-random-keystream
So if we know plaintext and crypted, we can get the keystream, and with the keystream, we can encrypt our own code. It goes like that:
guessed-pseudo-random-keystream = crypted xor plaintext
new-crypted = guessed-pseudo-random-keystream xor plaintext-patch
You could think there's a chicken and egg problem, how did we get plaintext in the first place?
Easy: we had plaintext CBs from fat consoles, and we thought the first few bytes of code would be the same as the new CB_B, so we could encrypt a tiny piece of code to dump the CPU key and decrypt CB_B!
The NAND contains CB_A, a patched CB_B, our payload in a custom plaintext CD, and a modified SMC image.
The SMC image is modified to have infinite reboot, and to prevent it from periodically sending I2C commands while we send ours.
Now, maybe you haven't realised yet, but CB_A contains no checks on revocation fuses, so it's an unpatchable hack !
Caveats
=======
Nothing is ever perfect, so there are a few caveats to that hack:
- Even in the glitch we found is pretty reliable (25% success rate per try on average), it can take up to a few minutes to boot to unsigned code.
- That success rate seems to depend on something like the hash of the modified bootloader we want to run (CD for fats and CB_B for slims).
- It requires precise and fast hardware to be able to send the reset pulse.
Our current implementation
==========================
We used a Xilinx CoolRunner II CPLD (xc2c64a) board, because it's fast, precise, updatable, cheap and can work with 2 different voltage levels at the same time.
We use the 48Mhz standby clock from the 360 for the glitch counter. For the slim hack, the counter even runs at 96Mhz (incremented on rising and falling edges of clock)
The cpld code is written in VHDL.
We need it to be aware of the current POST code, our first implementations used the whole 8 bits POST port for this, but we are now able to detect the changes of only 1 POST bit, making wiring easier.
Conclusion
==========
We tried not to include any MS copyrighted code in the released hack tools.
The purpose of this hack is to run Xell and other free software, I (GliGli) did NOT do it to promote piracy or anything related, I just want to be able to do whatever I want with the hardware I bought, including running my own native code on it.
Credits
=======
GliGli, Tiros: Reverse engineering and hack development.
cOz: Reverse engineering, beta testing.
Razkar, tuxuser: beta testing.
cjak, Redline99, SeventhSon, tmbinc, anyone I forgot... : Prior reverse engineering and/or hacking work on the 360.
Official Site: GliGli Github
Download: Here
Tutorial/HowTo: Libxenon.org
News-Source: XboxScene
NEWS VIA WWW.XBOX-SCENE.COM
-
Oh, and I forgot to mention the Xbox I was given was a Crystal
-
I got an XBOX for softmodding another XBOX....go figure
-
As far as i can tell, with the beta's i have, these issues have been sorted out in the Madmab editions.
Rayman etc worked a while ago in the new beta's so go figure !
So, Rayman works in V2??
Iv'e tried loading it, all I get is a freeze at the ubisoft logo?
what are you using..Bin/cue or the sub/ccd/img?
and if your using the sub/ccd/img what file do you load in the emu?
Thanks
-
to get rayman to work, some1 with a real copy will need to rip it to img/sub/ccd format with cloneCD
I have the img/sub/ccd format version of the game.
Iv'e tried it on the PC version of PCSXR and it still freezes at the ubisoft logo?
the BIN/CUE version of the game plays fine but music is off.
-
i think i will have a crack at trying to get rayman to work on pcsxbox this weekend,i have it on the sega saturn and i love it.
Dude you are officially King
RAYMAN!!
Thanks
-
Is Rayman working for you on the latest Coinops?
I have not tried it, but to be honest i doubt it.... CoinOPS uses the core from PSX Emu your already using so if it dont work on there it wont work on coinops
soz bud
Dang it, nevermind then:P
Do you know why Rayman doesn't work? is it something to do with the cdda audio not being emulating correctly?
-
Is Rayman working for you on the latest Coinops?
-
ac3t1ne, did you get around to testing it?
I'd Love to play this game
-
May I have the link please.
EDIT: got it
-
Does Rayman work?
-
Well, it wouldn't be a 360 it'll rrod in the first 12 months.
Mine would probably be a xbox 1 fully loaded with Emulators and films/pron
Team-Xecuter presents '14717 RGH'
in XBOX Hacks [/xbox]
Posted · Edited by ploggy
Team-Xecuter presents '14717 RGH' – Dual CB Glitch Achieved on Slim – Phat Next
Team-Xecuter been really working fast and hard these last few days and they done it again with news report of getting RGH working Microsoft Xbox 360 Console running on the v14717 dashboard without need of a previous dump or CPU keys!
NEWS SOURCE: http://team-xecuter....slim-phat-next/
VIA: http://www.ps3crunch...80%93-Phat-Next