Now this is what I like to hear :yipi: :yipi: :yipi: :yipi: :yipi: :yipi: :yipi: :yipi: :yipi:
QJ Wrote:PSP-Generation claims Dark_Alex's planning to push 3.30 OE custom firmware out the receiving door within "48-72 hours". Given the timings between the news on April 1 (it's just a calendar date, after all), and the 3.30 decrypter, this claim is quite credible on the best analysis.
The devil is in the details, though. PSP-Gen explains that Dark_Alex found 3.30 using up quite a lot of the PSP's flash memory, which is complicating efforts to add bonus functions. Hence, the 48-72 hour thing: he's trying to make up his mind between releasing 3.30 OE as is, and add bonus functions through patches later, or release it later with the bonus functions built in.
Well, so far as current PSP games aren't demanding 3.30, maybe it can wait, but with the improvements to movie playback...
QJ Wrote:This program was originally created by Tommydanger to help those who are rather afraid of installing new firmwares to DevHook. And anyone who has used this before will agree that it is quite noob-friendly and it takes away all your homebrew fears. That doesn't mean though that you will not take precautions.
Anyway, Sleepy566 said that as of the moment, there are no known issues for DevHook Firmware Installer v0.6h. Everything is ready to run, as the coder included the customized Devhook 0.52010000. And as such, it should run on all known firmwares. Below is the complete changelog for this version. Please make it a point to browse through the Readme file before using this.
Version 0.6h
* Bug fixes corresponding to previous version's additions
* Added newest Devhook and folders for all the firmwares you could decrypt (though unsupported)
Version 0.6g
* Added full support for 3.30 (didn't forget anything this time)
I finally managed to download the 3.30 update so I could have a little look at some RCOs...
visualizer_plugin.rco
Firstly, I say, there's nothing to be excited about this one. All the RCO contains is 14 images (I checked by searching for the signature; the header indicates that no more than 15 images are in there though). Also contains what appears to be a "blank" (unused/useless) page resource.
As for the purpose of the images, I don't know. I guess it's possible that the some of them are used in the visualizations, but making your own effects won't be possible by editing the RCO.
topmenu_plugin.rco
The 1 or 2 extra page resources present in the 3.10 topmenu (which was what caused the problems) aren't present in the 3.30 topmenu, and the 3.30 topmenu's header is only 668 bytes longer than the 3.0x one (both unpacked), so yes, 3.30 OE will almost certainly be customizable :)
Interestingly, though, the icons in the 3.30 topmenu take up less space than the 3.0x topmenu
Since topmenu's a large RCO, I'm too lazy to do any further investigation, but I can say that custom icons will most likely work on 3.30 :D
In what could be the most embarrassing exploit to impact Windows Vista since its commercial launch in January, security engineers at McAfee’s Avert Labs confirmed today - and posted the video to prove - that the operating system can be caused to enter an interminable crash-restart-crash loop, by means of a buffer overflow triggered by nothing more than a malformed animated cursor file.
It isn’t even a new exploit, as researchers with eEye discovered in January 2005. At that time, Microsoft acknowledged it affected versions of the operating system from the first edition of Windows 98 through to early releases of Windows XP, though it stated at the time XP SP1 was unaffected.
But apparently after researching field reports of limited attacks, Avert Labs discovered an apparently similar exploit using .ANI files impacts XP SP2 and Vista, as well as Windows 2000 SP4 and versions of Windows Server 2003 from the initial release through to SP1. Avert Labs stated XP SP1 and versions since were unaffected, though Microsoft warned the exploit does affect XP SP2.
If both firms’ accounts are correct, Microsoft may have fixed the problem with XP SP1 in 2005, and inadvertently un-fixed it sometime afterward.
Avert Labs’ video of the incident, posted to YouTube, shows a Vista system wherein the test file apparently trying to load the custom animated cursor. When the operating system detects a crash, it first tries to save vital data prior to a restart sequence - one of Vista’s newer features. It then informs the user that Windows Explorer has crashed.
But in trying to restart Explorer, the restarting crashes itself, sending Vista into a tailspin from which the only escape appears to be the off button.
The mouse input routines in Windows are designed with the intention of being relatively failsafe. That’s why when the system appears to hang, you can often still move your mouse pointer. As I’ve personally witnessed on many occasions with Windows XP, it’s possible for a smaller OEM’s mouse driver - often an unsigned one - to trigger a similar tailspin loop that crashes Windows Explorer repeatedly. In Windows, a lot depends on the mouse pointer’s very existence.
So if a customization feature can impact the mouse pointer’s ability to function, the integrity of the entire system can be jeopardized. With my own systems, drivers and services that are unfriendly to one another - such as Stardock’s CursorXP animation program trying to co-exist with a Synaptics Pointing Device driver on a notebook with ATI Mobility Radeon 9600 graphics - can trigger an Explorer tailspin.