- Join Date
- Apr 2005
PS3MrEnigma on PS3 Mount Points, FileSystems and Alejandro
As a follow-up to his previous article, today ps3mrenigma details PS3 Mount Points, FileSystems and Alejandro on his blog (linked above).
To quote, roughly translated: Following the publication in the day yesterday the source code indicating the SYSCALL used for the assembly system is no longer necessary for security, keep this information privately, and whether the information actually had not been published by my, despite claims to the contrary by many users, was to prevent misuse and attack the flash, anyway as I said in my last post we had in mind when it was polished release something new, everybody is free believe us or not, but it is.
For more information, an old post of mine: http://ps3mrenigma.wordpress.com/201...eversing-post/
As is the case, step assemblies are writing, how they work, and which are assembled and disassembled as explaining in turn the SYSCALL used in the process.
First of all understand that this post is a technical post, so that many users will serve you for nothing more than for your personal knowledge, which I think is worth more than any other program exists or can be made to root it.
NOTE: This post is original, you can gradually expand as arranging information in case something is not quite accurate.
REPEAT is an initial post to explain this issue. Of course anyone who wants to help is welcome to leave comments.
Utlize the PS3 system setups similar to what might be to mount a drive in a Linux environment.
The first thing listed is the type of drive that let's ride, which specifies a string of the following:
- CELL_FS_DUMMY: This type of unit is used in machines to mount a drive Retail DUMMY (ie, exists but does nothing) in unity "/ app_home." This type is also used in the Debug or RefTool machines in the event that starts the Release mode.
- CELL_FS_HOSTFS: This type of unit is used for mounting the unit "/ host_root" and "/ app_home."
- CELL_FS_IOS: BDVD_DRIVE: This type of unit as the name suggests is related to the unit "/ dev_bdvd" in a generic way.
- CELL_FS_IOS: PATA0_HDD_DRIVE: Indicates the type of unit to mount the "/ dev_hdd0" this type is used in models such as Phat of 60 gigabyte.
- CELL_FS_IOS:PATA0_BDVD_DRIVE : Tipo de unidad que ayuda a montar la unidad "/dev_bdvd", este tipo es utilizado en los modelos por ejemplo Phat de 60 gigas. - CELL_FS_IOS: PATA0_BDVD_DRIVE: Type of drive to help mount the "/ dev_bdvd" this type is used in models such as Phat 60-gig.
- CELL_FS_IOS: PATA1_HDD_DRIVE: Indicates the type of unit to mount the "/ dev_hdd0" this type is used in models such as Phat of 60 gigabyte.
- CELL_FS_IOS: PATA1_BDVD_DRIVE: Type of drive to help mount the "/ dev_bdvd" this type is used in models such as Phat 60-gig.
- CELL_FS_IOS: BUILTIN_FLASH: Type in the mounted unit that specifies a generic flash drive, eg / dev_flash. "
- CELL_FS_IOS: COMPACT_FLASH: Compact Flash type unit to help mount the unit "/ dev_cf." Logically only for models that support it internally.
- CELL_FS_IOS: MEMORY_STICK: Like the previous aid in mounting the unit "/ dev_ms." As with the previous one only if it is supported internally.
- CELL_FS_IOS: SD_CARD: SD_CARD type unit to assist the assembly uniadd "/ dev_sd." You need to have internal support.
- CELL_FS_IOS: USB_MASS_STORAGExxx: Type of drive to help assemble the units "/ dev_usbxxx." xxx can be any numeric value starting from the 000 for the unit "/ dev_usb000", etc.
- CELL_FS_IOS: USB_MASS_STORAGE: Same as above but to mount a generic "/ dev_usb."
- CELL_FS_IOS: BUILTIN_FLSH1: Type of unit suitable for mounting the "/ dev_flash" only.
- CELL_FS_IOS: BUILTIN_FLSH2: Type of unit suitable for mounting the "/ dev_flash2" only.
- CELL_FS_IOS: BUILTIN_FLSH3: Type of unit suitable for mounting the "/ dev_flash3" only.
- CELL_FS_IOS: BUILTIN_FLSH4: Type of unit suitable for mounting the "/ dev_flash4" only.
- CELL_FS_UTILITY: HDD0: Hard HDD0
- CELL_FS_UTILITY: HDD1: Hard HDD1
- CELL_FS_UTILITY: HDD2: - No Information -
- CELL_FS_UTILITY: HDD: Hard Disk
- CELL_FS_PSEUDO: - No Information -
- CELL_FS_ADMINF S: To be used in the assembly of the unit "/ app_home."
The second thing to point out is the type of file system that we use in that unit, indicated by a string of the following:
- CELL_FS_DUMMYFS: Just a DUMMY file system, to be reported in the IOS DUMMY seen before.
- CELL_FS_ADMINFS: To be used with the IOS with the same name.
- CELL_FS_FAT: To mount a drive using the FAT32 file system.
- CELL_FS_SIMPLEFS: sometimes used by hard drives and flash2. It is mainly used to check if the drive is formatted in this way allows the formatting of the drive.
- CELL_FS_UFS: To mount the hard drives, as we shall see later.
- CELL_FS_UDF: To mount the drive "/ dev_bdvd."
- CELL_FS_ISO9660: Allows you to mount drive.
- CELL_FS_EFAT: - No Information -
- CELL_FS_PFAT: - No Information -
The third thing to specify is the name of the unit in a string, the name of unity has to be a drive name recognized by the system for the unit to be mounted.
It can be one of the following:
- / App_home: Unit to have a filesystem on a remote computer as a PC. Also used for debugging environments.
- / Host_root: In conjunction with the above.
- / Dev_bdvd: The BDVD drive.
- / Dev_flash: The master flash unit, where most of the firmware is housed.
- / Dev_flash2: flash drive that stores the registry with the configuration of the system, for example.
- / Dev_flash3: Third flash drive with system files. It is advisable to back up her as well.
- / Dev_flash4: Unknown, appears indicated in IOS, but still do not know if its existence is real or that could be your real name or use.
- / Dev_hdd0: The unit's internal hard disk of the console, which for example would be the demos, etc..
- / Dev_hdd1: Second primary disk drive, used primarily as a cache.
- / Dev_usb: usb-generating unit.
- / Dev_usb000 - 127: USB Drive specifying the port to use for the number being 0 port to the far right of having the machine. The 1 would be the adjacent to the left, and so danddo around all the numbers.
- / Dev_cf: Compact Flash Unit.
- / Dev_sd: Unit SD card.
- / Dev_ms: Unit for Memory Stick.
Knowing this I'll explain the error codes we can find in the case of a failed installation or removal:
- ERROR_KERNEL_ARGUMENTO_INVALIDO: 0 × 80010002 -> This error occurs when we specify any argument to the call of the SYSCALL improperly or nonexistent, such as a null pointer, but could also be reported in the case of sending a combination not recognized or a bad combination of parameters to lv2.
- ERROR_KERNEL_DEVICE_BUSY: 0x8001000A -> This error occurs when trying to remove a unit that still has any active link, such as a file descriptor, etc.
- ERROR_KERNEL_I / O_ERROR: 0x8001002B -> appears when there is no machine that model / firmware a particular IOS, or when despite being a right combination of parameters that the unit can not be found, for example, an inserted USB the appropriate port, etc.
- ERROR_KERNEL_INVALID_MEMORY: 0x8001000D -> When specifying a pointer incorrectly or in a memory region is not allowed.
- ERROR_KERNEL_8001003B: 0x8001003B -> Appears when a unit is mounted bdvd bad, but not know its real meaning.
- ERROR_KERNEL_ILLEGAL_ACTION: 0 × 80010009 -> precisely that reason, some firmware security check prevents that action can take place.
- SUCCESS: 0 -> The return value on success.
After these explanations we see the SYSCALL that affect what we mean.
As indicated on the post
That is why we use the SYSCALL 838 -> lv2FsUnMount this:
For example, to remove the primary flash:
Int ret = lv2FsUnMount ("/ dev_flash"); "
The unit specified must exist or else ARGUMENTO_INVALIDO receive the error, just as the unit must be free to be occupied, or else we will find the error DEVICE_BUSY.
Once successfully performed this operation, the unit will be disassembled and THEREFORE NOT ACCESSIBLE.
For example, for you to try this SYSCALL make a program that BDVD disassemble the unit, installed in the machine, and then enter a game in the PS3 XMB, XMB will recognize when to start your application and remove the drive, then exit it, when you return to the XMB the drive still appears visible, with the name of the game even (this is because the VSH information that was saved, and PARAM.SFO), but if you try to access the disk you will see that I returned an error that the unit is not mounted,
INFORMATION ABOUT 'ALEXANDER':
At this point I'll explain how it worked 'Alexander' in order to successfully perform disassembly of the main flash.
As you can see if you realize a program that attempts to remove the flash from the XMB, you will find the final DEVICE_BUSY error. Esto es normal. This is normal.
Entonces, como desmontaba 'Alejandro' la unidad?
Then, as he dismounted 'Alexander' the unit? Really 'Alexander' not dismount, I did was change the name on the board assemblies "/ dev_flash" so then the next one could be mounted.
WARNING: For the system in case of failure to rearrange the drive name to what was, by going into the XMB, the system would think that since there is no flash for was removed. That is why if 'Alexander' failed at some point in the process expecificaba turn off the console with the power cord or switch back.
That is why if we do something with an existing unit, the first thing we have to do is remove it using SYSCALL or else forcing the "removed" on the mounting board.
As put in the post:
Indeed, the key SYSCALL this process is the SYSCALL 837 -> lv2FsMount.
To mount the flash drive would use this sentence to the previous presumiento were removed:
Int ret = lv2FsMount (CELL_FS_IOS: BUILTIN_FLSH1 "," CELL_FS_FAT "," / dev_flash ", 0, MODE, 0, 0, 0);"
Where MODE can be a value between 0 / 1.
- WRITE_PROTECTED : 1 - WRITE_PROTECTED: 1
- WRITE_NOT_PROTECTED : 0 - WRITE_NOT_PROTECTED: 0
As can be seen here was not any exploit or anything like that as some users are hard to say without having any idea of how the "Alexander" and even worse without even knowing how the system worked inside the PS3.
Of course try to mount the drive as writable BDVD logic fails.
I hope this post has been somewhat lighter assembly system, access and permissions.
Now you just need to try them all, OF COURSE WITH CAUTION, before making foolish to think the consequences.
Utilities that have this are endless, from the example given with 'Alexander' to create emulated virtual drives, eg drive, usb (this is done by the system), and many more.
As long as I JaiCraB both indicated that you can leave your comments both positive and negative impacts on the blog.
More PlayStation 3 News...
12-19-2010 #2ha9 Guest
Thanks for this amazing update.
12-19-2010 #3jakob777 Guest
WOW, that is a ton of info. I know I am not ganna get all of this but I am sure there is ganna be a ton of people that will get a great amount out of this. Thanks for the hard work putting this together and sharing!
12-20-2010 #4crax0r Guest
With this info on hands we can now:
1) create real dev_bdvd redirections of hdd folders
2) mount 2tb usb drive formatted as UDF, making it possible to store files >4gb)
12-20-2010 #5deank Guest
It is amazing how none of these two is possible... just read the post again.
Also you'll be a superhero if you manage to format any HDD with UDF filesystem.
12-21-2010 #6crax0r Guest
here you go:
Windows Vista/7 (maybe xp too), don't use /q (quick format)
format <driveletter>: /fs:UDF
12-21-2010 #7deank Guest
I spoke too soon. Windows doesn't have a parameter to set UDF type (like 2.50), but I got a spare 74GB external USB HDD and I'm formatting it with UDF under Vista. I'll post later if I have any progress!
Thanks for the tip!
12-21-2010 #8hacked2123 Guest
12-21-2010 #9deank Guest
Of course it supports 4GB+ files. All Blu-ray movie discs use UDF 2.50 or 2.60 and there are files of 20-30GB in size. The problem is that I have no idea what will happen with a HDD formatted as UDF (which is basically for optical media).
12-21-2010 #10vicx Guest
with hp fortmat tool you can force to format a hdd in udf 2.5 mode i think i tried this a few months ago ! i hope i am right!