forums.ps2dev.org

Sigh, really it isn't psplink crashing. I would assume python is just fucking with the wifi. You really shouldn't use the old psplink wifi stuff anyway, it was always a hack job to allow people to use _something_ if they were too cheap to build a serial cable.

J.F. trust me on this, there is _always_ a way of getting it to work. I just guess you didn't understand the ramifications of how the linker does its job. Of course it is a limitation on the import system (I take responsibility) and its mechanism to handle stripped down imports, but it is better to ...

Well it shouldn't be possible for that error not to go away as you can always ensure that the SDK libs are linked last :)

Well then just implement your own malloc wrapper, the way malloc is defined means you can just replace it with what ever you want, it is only an issue if the library uses its own internal malloc which you can't override.

Unfortunately if I recall sceAllocPartitionMemory allocates fixed sized chunks of memory, so if you has alot of small allocations it would quickly nuke all of memory, which is why you need some sort of heap management. Malloc is standardised, if you don't like it you don't have to use it, or any of ...

Dump the UID table when you threads are failing with out of memory errors and you can see what has been allocated in the SysMem block (they should all have half sensible names if you are lucky :P), of course it could also be FPL/VPLs and all manner of other things eating memory space.

"Exception - Address load/inst fetch" wasn't clear enough for you, for fucks sake. The error says it is a load exception, i.e. you gave a garbage address to something. The faulting instruction is a load word from $a0 and $a0 is set to 0x7FE and obvious garbage address. No doubt you could h...

I would assume that the header does not extern C the function definitions so when compiled g++ is trying to find the mangled form which doesn't exist.

Hmm a bug surfaces :) The problem is GDB implements a range restriction on what addresses it is willing to read to prevent GDB itself from crashing. Unfortunately now people have forced psplink to run with the large memory model on slims your stack frame is above the old 32MB limit and GDB refuses t...

You didn't honestly add PSP_HEAP_SIZE_KB(-64); to the main.c of psplinkusb did you? You are lucky psplink doesn't use the heap at all otherwise that would have fucked everything up :)

yah, if you do prxtool -f systimer.prx then the addresses of the functions is in the [], the alloc function is at address 0.

prxtool wont display everything as disasm and hex. It only disassembles (unless you force it) the .text sections. Seems that prx has the module info/imports rammed into the .text section which is what causes the data to be disassembled. As for missing sceSTimerAlloc, that is probably a bug in the an...

Of course if you are using GDB then you shouldn't see these errros on the main window, unless you are crashing somebody else's module/prx. GDB will only handle exceptions in the code which it loaded.

Aligning read buffer to 64bytes can be beneficial, especially when reading/writing to usbhost (cause I know how I implemented that).

WEll yes you _can_ have a module which exists in all modes, but you cannot have one which doesn't reinitialize :)

no

Perhaps you keep forgetting, you don't need the HMAC key, at least for the IPL that can be brute forced in a few days for a single encrypted block which is all you need :) All you need to do is find the method of data encryption/decryption and job done. It is worth remembering that the encryption it...

For the IPL at least the key is in the clear, it is at the start of the block. It was noted that by adjusted the first 32 bytes certain parts of the output decrypted differently. Of course we don't a) know what algorithm they chose, or at least if we can guess (say AES) then they probably have some ...

Of course you might not actually want to use large memory support depends on what you are trying to target ;)

Ahuh, expensive hardware. About the only way of probably getting the pre-ipl would we to decap the chip containing the pre-ipl and read it out using a microscope :)

The current path is taken from the first argument passed to the module in sceKernelStartModule, I assume you are not passing anything to it :)

If 'reset' is locking up it is generally the fault of the application and not psplink per-se, there are some situations where the kernel just will not reboot and the app keeps handing on. Make sure you don't have any tight loops with no wait states in them (like waiting on vblank or an event).

Cunning bastards :P

There is a pipe primitive in the thread libraries you could use, however the issue comes down to having to pass those UIDs around, unfortunately each module/eboot does not get its own file descriptor table like on unix so you couldn't just use stdin/stdout/stderr. Of course if you are willing to wri...

The registry exploit has been fixed (it got fixed in the next revision of the firmware), Sony also added code to make it more difficult to do the attack on the memory protection registers as well while they were at it. I can't remember what kernel exploits are known and fixed or not known, also poss...

Sigh!!! I might as well lock this thread, it is like 2005 all over again, with the pointless speculation. Lets get some points clear... * Encryption/Sign Check is done in hardware, you would have a job changing the keys. * The signing check relies more on a HMAC algorithm it seems then real signing ...

For a start, psppacker (DA's hack of the ~PSP stuff) is dependant on the the CFW stuff. Breaking the crypto is none-trivial, it could take millions of years, pandora only works because they fucked up, badly...

You cannot use telnet with psplinkusb, it doesn't work. End of story

Well because it is a closed architecture (and it needs to be to support their business model) it is imperative to prevent against just adding a modchip :)

If I was doing it I would have fuses in the CPU die which could blow to take out the jtag, do your hardware test then at final test time you take them out, certainly i have heard rumours of the test pins being identified but them not actually doing anything.