forums.ps2dev.org

I had a quick look at the implementation, and it seems to me that

*udst-- = *usrc--;

should really be

*--udst = *--usrc;

PSPSDK does not provide a ctype.h of its own, so you are actually using the newlib ctype.h. However, since you are not _linking_ with newlib, the global ctype table used by the header file will not be available. The reason it works with optimization is probably that the code which actually uses ctyp...

I can do it if you give me write access. ;-)

Here's a patch for the endianness issue with (un)pack-pbp.c:
endian.patch

config.h.in will have to be regenerated too (is it a mistake that it is under version control? I expect so...).

getopt_long is in libiberty.a if your platform libc doesn't have it. Yes, but the SDK does not link against libiberty. This can be fixed of course, but since libiberty might not be installed either, a better idea might be to include the getopt_long source from libiberty into the PSPSDK distro, and ...

Nick Fury wrote:It's time you discovered an updated OS my friend.

I see you are making a valuable contribution to making the SDK more portable. Keep up the good work.

Seing as only one option is supported anyway, it shouldn't be a major issue to do without the call to getopt_long()... :-) /* Process the arguments */ int process_args&#40;int argc, char **argv&#41; &#123; int i, ret = 0; g_printpath = 0; for&#40;i=1; i<argc; i++&#41; if&#40;...

I do. Solaris 9.

Solaris < 10 for sure. I'd _assume_ that IRIX, AIX, UNICOS et al don't have it either, but my test machines seem to be inaccessible at the moment. getopt_long() is a GNUism to begin with.

psp-config is already unportable, since it uses getopt_long...

I use a simple shellscript instead.

pic1.png is a different picture. You probably mean "pic0.png", which is the name that it logically ought to have, although I don't know if anyone has verified that this is the "real" name. (Just plonking a "pic0.png" into a savegame diectory does not seem to have the de...

Orion_ wrote:maybe but I can't see the library name in the elf file :/
thats why I say that

Look harder. Hint: The name of the library is "sceDisplay".

Orion_ wrote:I'm not expert in Elf file format but it seems not to call any system function, so this use pure hardware hack ? O_O

It calls firmware supplied libraries (compare with libfoo.so), which may use syscalls, bang the hardware, or whatever.

There is no such thing as a "public AES key", AES is a symmetrical crypto.

And no, a fixed AES key would most likely not be used. Instead, a unique key would be generated for each release, and encrypted using an assymetrical crypto, and then stored in the DATA.PSP.

Or follow this link.

I am still not clear on the RSA's Publik Key Infrastructure. I assume that the main idea is having public and private key to decrypt a file. Not quite. You only need one key to encrypt and only one to decrypt. If you encrypt with the public key, you need the private one to decrypt. If you encrypt w...

Looks like a subliminal message trying to get you to SUBMIT. Next thing you'll probably get a screen prompting you to OBEY or CONSUME. :-)

Btw, the mass storage specifications can be found here: http://www.usb.org/developers/devclass_docs#approved
Look under the "Mass Storage" heading.

I'm not trying to put you down or anything, but what exactly are you planning to achieve by snooping the USB bus? The protocol used to access the memorystick is regular USB mass storage, which is well known and documented, and the actual data carried will be exactly the data you read and write from ...

Argle bargle glop glyf?

There's nothing to say that the numbers in this particular sequence are necessarily of the same "kind", we could very well have one offset, one length, one load address, or whatever. It doesn't look like all can be sizes though. And they don't look like checksums. Speaking of checksums, I ...

This is a possibility, and pretty much what the SSH protocol does, but it's unlikely that the secret key is in the SDK, so this would mean that Sony has to encrypt each and every PSP or PSAR, it's a big job, perhaps they have grant developers access to a shell server to encrypt their own binaries? ...

I seriously have about given up on ps2dev - a lot of you guys whine, troll, or whatever, but you don't actually write any code or provide any useful information or encouragement to beginners. playstation2-linux.com does do that and much more. And guess what? It's officially supported by Sony. It se...

I expect the "utility applets" are stuff like the screen you get when pressing HOME. As far as could be seen from the SFO experiments, the XMB interface is a normal application running in user space, and not part of the 8MB kernel.

I noticed something sort of interesting... there is in fact an 'escape' character. Well, there seem to be too. Both 0xE2 and 0xE3 both seem to be escape characters to map to ?unicode?. That is how the TM characters is created as well as the japanese letters. RTFM UTF-8. :-) What I don't understand ...

USB mass storage devices do not work with "files", they work directly on sectors. So the PC asks for some sectors of the "disk", and then has to figure out for itself which files exist, etc. Filesystems often do not eradicate all information about a file when it is deleted, they ...

It would probably help if you ran gorim's "psfparse" on either of these files and posted the result here...

Well, now you're assuming that the transferred game is somehow compiled into the main binary. If it's just a file on the UMD, the main application doesn't really have to care about the contents, and so it will be no difference in operation when you are using an unencryped file during development, or...

Odd, considering all other strings are UTF-8...

Anyway, Shift-JIS has ideograpic space at codepoint 0x81 0x40, so if all else fails, you should be able to use that. It might be slightly wider than a regular space though...

That's reassuring. :-) First glance at the PSAR files did not give very much. The first 16 bytes of the file from the phony update are: 000000 50 53 41 52 01 00 00 00 60 a4 aa 00 01 00 00 00 and for the real update: 000000 50 53 41 52 02 00 00 00 20 de 9a 00 01 00 00 00 After this the data is comple...

[quote="Minase"]I'd be very surprised if the media player doesn't have a multitude of bugs waiting to be exploited... considering how many times overflow or similar bugs have been found in software like ffmpeg and mplayer (of course, on a PC this is nothing special, but on the PSP...), whi...