[Lazyass]

why ''we'' can't dump ram when TB eboot is decrypted in it and than look what is diffrent ?
is there any chance that eboot is signed with 3.55 keys and added some lines that says ''elf (is this executable file or what?) can be executed IF ''drm'' keys (which are writen on the start of lines or in header or whereever they are) can be decrypted with TB Dildo'' ?


yust idea on knowledge i get in few months of reading everything about ps3 stuff

[GregoryRasputin]

Originally Posted by Simonbuck Some of you so called "Dev's" are a bunch of C**nts as far as I am concerned, you write your little Wiki as the its the FU***in Bibble, you wont listen or help anyone else who wants to have a go, you are the most selfish bunch of C**nts I had the miss fortune to listen too. "

ummmmmm C*nts only has four letters, your spelling seems to have five O.o

[Simonbuck]

^^^^ LOL

More than 1 plural ??

sorry got over exited with the swear mask "****$@###***"

[svenmullet]

Originally Posted by enosrasun ok ,try this if you can log the tb dongle,you don't need the keys this can be done with a real tb dongle the ps3 send 1 encrypted pack , the dongle receive it and send the response to ps3 you don't need the key only the right pack (the pack that ps3 is waiting) the key is use to decrypt the pack to see what is in it so the ps3 sends "hello" (encrypted ,can be "gjujdfu") the dongle decryt it and sends back "hi xxx" (encrypted can be "gfgerou9") you need the key to see it as "hi xxx" but the ps3 expect "gfgerou9" when he sends "gjujdfu" (hello) ps like when you copy at school ,you don't know what you copy (encrypted for you ) but is the correct answer for the problem

First off, I think you have it backwards: the PS3 sends a plaintext string (which is random) and because it knows the algo/key, it expects the dongle to return the same string in encrypted form. Secondly, if you could spoof the entire authentication routine by carefully studying a protocol analyzer dump and send it, for instance "00000000" as the plaintext and it returns "*j63hj*9" as the response, can you deduce the algo/key from that? The algo could be something involving byte-reversal, substitution, shifting, anything under the sun. *Then* encrypted with a key. It's mathematically impossible to figure out, in other words. People have been trying to dump the rom on it and reverse that, but the MCU they used has so much security on-die that even a dump of it's contents is impossible to reverse, as the rom itself is encrypted (the MCU decodes it's own rom in realtime). They used ProASIC for a reason. If you could, over the course of a very long time, send it every possible combination of plaintext and log all it's responses, you might eventually figure out what the algo/key is, but that's not gonna happen.

And for the last time: dongle=red herring. If you don't know what a red herring is, please refer to this page.

[fuRh7]

Originally Posted by ElSalvatore Well, I know that we wouldn't need the Dongle anymore. I'm just saying that we still would need TB to publish EBOOTs, which we could (IF I'm understanding it right!) "unsign" and "resign" with 3.55 code. or am I wrong? (I'm just asking!)

Sorry. Youre right. But i'm sure TB wouldnt publish eboots anymore.

[mirkie]

Originally Posted by svenmullet First off, I think you have it backwards: the PS3 sends a plaintext string (which is random) and because it knows the algo/key, it expects the dongle to return the same string in encrypted form. Secondly, if you could spoof the entire authentication routine by carefully studying a protocol analyzer dump and send it, for instance "00000000" as the plaintext and it returns "*j63hj*9" as the response, can you deduce the algo/key from that? The algo could be something involving byte-reversal, substitution, shifting, anything under the sun. *Then* encrypted with a key. It's mathematically impossible to figure out, in other words. People have been trying to dump the rom on it and reverse that, but the MCU they used has so much security on-die that even a dump of it's contents is impossible to reverse, as the rom itself is encrypted (the MCU decodes it's own rom in realtime). They used ProASIC for a reason. If you could, over the course of a very long time, send it every possible combination of plaintext and log all it's responses, you might eventually figure out what the algo/key is, but that's not gonna happen. And for the last time: dongle=red herring. If you don't know what a red herring is, please refer to this page.

Tell me, where did you get this information from? I hope it's not from your fantasy world, because you can't know that without seeing the source or packetlogging the data.

Edit:
Also if your theory was right, we still could decrypt it. If we send all characters possible to the dongle, it will send the encrypted version of it. This could be done with something called a... computer.

And the big If is, IF you were right.

[enosrasun]

Originally Posted by svenmullet the PS3 sends a plaintext string (which is random) and because it knows the algo/key, it expects the dongle to return the same string in encrypted form.

I don't want to decryt the answer only to copy it and send it ..

[bigo93]

Originally Posted by GregoryRasputin ummmmmm C*nts only has four letters, your spelling seems to have five O.o

Counts?? Devs are Counts now?

[euss]

Originally Posted by svenmullet [...] They used ProASIC for a reason. If you could, over the course of a very long time, send it every possible combination of plaintext and log all it's responses, you might eventually figure out what the algo/key is, but that's not gonna happen.

1. Not all reDRM dongles uses Actel with AES.

2. Actel's implementation of it is limited and flawed.

3. Not all data is in Actel, but in SPI

4. All data, sent encrypted over USB must be PPU/SPU readable in its endform.

5. Peek/poke isnt the only transport mechanism for binairy data inside the PS3.

6. EBOOT's, no matter how encrypted they are, must be PPU/SPU readable to be run at the end of the pipeline of jumping hoops, hashchecking, section extraction, capability checks etc.

7. The power of an encryption is measured in amount of investment and effort needed to render it useless.
Its target audience is people that want quick cheap candy without using brains/effort/money and in general people that like challenges, encryption, hacking, documenting, tracing, reversing like a real reward - not some games they already have or some closed limited cake to win (it aint Portal).
So in that weighing, it is pretty effective.
I know I certainly will not put alot of effort into it, besides the effort already published and I certainly will not lower my morals by sending money to donglesellers to be able to do afformented tracing etc.

[svenmullet]

Originally Posted by mirkie Tell me, where did you get this information from? I hope it's not from your fantasy world, because you can't know that without seeing the source or packetlogging the data. Edit: Also if your theory was right, we still could decrypt it. If we send all characters possible to the dongle, it will send the encrypted version of it. This could be done with something called a... computer. And the big If is, IF you were right.

I don't usually respond to trolls (except for winding them up) but I'll make an exception here.

I "got this information from" knowing how cryptographic authentication works. Unlike you, I don't spout off bullsh*t of which I know nothing about. (Your revelation that the dongle sends 02 02 02 on powerup was fascinating) I tried to explain nicely that "02 02 02..." is standard USB protocol and you basically had an aneurysm. Then I tried to explain nicely that without the algo/key, you can try all day long to authenticate, and you won't ever do it, but your mind seems to be a brick wall. Now you're insinuating that I must have source code to know how basic authentication works. You, sir, are an idiot and a troll.