3.6x Timing attack theory for lv0

[Thecourier]

**Update:

Okay, so we need to set a goal. So we can stick to it here.

I say the first objective is (help or forget this thread exists), but we should find a way to dump lv0, there HAS to be a method of achieving that. If it was made by man it can be unmade by man.

xShadow125 You can update from your own pup only from 3.55 or lower, unless you have an exploit.
xShadow125 Of course that should be fixed in upcoming lv0 revisions anyway (By moving the ldrs to the top of lv0)
xShadow125 You run the 3.60 lv0, then you switch the nor, and pull the cell reset line, and you dump the extra KBs where the loaders are.
xShadow125 Basically you have a nor with 3.55 (or lower) lv0 and your own small lv1 code that does the dump, and 3.60 lv0 on the other.
xShadow125 You wont get all of lv0 but the part with the loaders shouldn’t be overwritten.
xShadow125 You can actually get all the 3.60 keys/loaders without knowing lv0 keys by dumping lv0 from ram with dual nor and signed lv1.
To those planning on building a 3.56+ pup for whatever reason, the files attributes changed, the group and user ids for the files as well.
The new 3.56+ values for tarballs are the following: owner_id, "0000764" group_id, "0000764" owner, "tetsu" group, "tetsu" ustar, "ustar"
You can use fix_tar to use those new values. Use with caution.
By comparison, those are the pre-3.56 values. owner_id, "0001752" group_id, "0001274" owner, "pup_tool" group, "psnes" ustar, "ustar"
Ps3WeOwnYoU You need to either decrypt or dump lv0, then you can get the encrypted loaders and decrypt them with the metldr key. Good luck.

Lv0ldr/lv0 is the target, and forget about the side channel timing attack for now. This theory above implies having a slim running 3.55 with a signed lv1 program to dump another (secondary/dual) NOR which has 3.6x on it, then using the boot process (with signed 3.55 lv1 program for dumping) to dump the ldrs because none should be written over. (summary of the above)



Chat is here: IRC: #PS3-36xDevChat @Efnet

Here's what we've got so far, this is a collection of the decent info from the other thread.

Scalar multiplication timing attack theory (possible 3.6x)

Hi, was just discussing this in general and someone suggested I make a post out of it. Anyhow, hear me out.

I'm not the type to wait for people to wipe my ass. Right now i'll be blunt, I'm looking at cryptography and Scalar Multiplication. Anyone else who's seriously interested in helping out get at me. This will be be a community project or it won't exist in the community, plain and simple.

*edit* and I don't care about "oh but then sony will find out what method you used", they would figure it out come release anyway. If anything, we all work on it together if we want it so bad.

*edit 2* this method isn't even going to touch sony code lines, it will be a standalone pc runtime (that's the plan anyhow) which can function with the ps3.

*edit 3* Bear with me, but this is the very beginning of my project, the code is horrible, the math isn't proofread, and it would NOT function as is. All it serves a purpose to do is express the theoretical expansion of hexadecimal growth with ternary+binary base emulation.

    {
    	int a;
    	int b;
    	int x;
    	int y;
    	int o;
    }

    {
    	if (a > b); {
      	  result = x; -1
    }
    {
    	else 
       	 result = y; 1
    }

    if (a < b) {
        result = x; 1
    else {
        result = y; -1
    }

    if (a = b) {
        result = x; 0
    else {
        result = y; 0
    }
        
    if (x = 0) {
        result = c-a; b
    else {
        result = a+b; c
    }

    if (y = 0) {
        result = b+c;  e
    else {
        result = b-c; -a 
    }

    if (x = 1) {
        result = a+a; 1
    else {
        result = b+b; -2
                ifelse {
                        result = b*a; 2
                  else {
                        result = a/b; 0.5 (or decimal equivalent)
    }

    if (y = -x) {
        result = a-a; -2
    else {
        result = b-b; -4
                ifelse {
                        result c/b ; 1.5 (or decimal equivalent
                  else {
                        result = b*a; 2
                                 ifelse {
                                         result = (a/b)+(a*b); 2.5 (or decimal equivalent)    
                                   else {
                                         result = (b*c)-(b/a); 4
    }
  
 if (x+y) {
        result = (a+a); 2
     else {
         result = (b+b); 4
                   ifelse {
                            result = (c+c); 3
                        else {
                             result = (e+e); 9
                                      ifelse {
                                               result = (c*e)+(e/c); 16.6
                                         else {
                                               result = (c/e)-(e*c); 14.4
}

I wanna take the software route, this project will have many more uses than just the ps3 if it makes it somewhere. Plus if you're broke and can't afford infectus2, this is really the best way to go.

Basically if this works, I'm gonna make a case that ECDSA security needs a rebuffing/new implementation. The goal is essentially an emulated quantum environment running elliptical curve (hex NOT hexadecimal) in combination with Scalar multiplication (exponential growth) equations as a means of buffer overflow you could say.

This project isn't designed with malice or hatred. I want security as a whole to better for everyone. We all deserve the right to privacy if we want it.

*edit* see here: http://eprint.iacr.org/2011/232.pdf

Note: When I say (or decimal equivalent) I mean for example 1.5, you could take 3/2 = 1.5, so 10/2=5. (1.5) would then equal 3.

This system essentially takes advantage of emulated fuzzy logic and base 5 math, 2+3 (binary + ternary). I'm also working on an exponential growth model which uses 2*3 and hex (base 6).

Any number with a geometrical value can be used in this stuff, especially for lattice attacks. You're looking for meshed protruding spirals in the code essentially. I'm weird and spent about 10 years of my life tripping about numerology then came to all this stuff. Old habits die hard, but geometry is one hell of a drug. XD

*Edit: Here are some raw equations from the TruHex grid geometry deal I linked:

Code:

4*3=12*2=24=2+4=6
12/3=4*2=8
12/4=3*2=6

Also, the important numbers i've noticed when doing 72/ are

72/6=12
72/3=24
72/48=1.5
72/12=6

72-12=60
72-24=48
72-42=30

72*3=216/6=36/6=6
72*5=360
72*6=432
72=12*6, 12 = 6*2, 6/2=3/2=1.5/3=0.5
:) Those are the ones of value i noticed.

72/1=72
72/2=36/6=6/3=2
72/3=24/4=6/3=2
72/4=18/2=9/3=3
72/5=14.4/3=4.8/3=1.6
72/6=12/5=2.4/3=0.8
72/7=10.2857142857/7=1.4(693)877551
72/8=9/6=1.5
72/9=8/6=1.33333333


Also, most of my work involves using 22/7 instead of Pi. (Pi =/= 22/7, in fact it's an approximation of it.)

TruHex:

Squared orientation
0.5*3=1.5

1.5*4=6

1.5*2=3


3*3=9

3+3=6

9*3=18

6+6=12

12*3=36


Trapezoid, X,Y squared orientation:
3*4=12
3+4=7


Protruding X formation, X,Y squared orientation:
1+8=9


Diagonal Z axis diamond orientation:

1/2 of trapezoid = 2, 1+1=2

Triangle Z axis diamond orientation:

if a= 2 and b= 2, c= 2

2*3=6

Top Pyramid multiple explanation:

The number in the top of the pyramid serves as a base multiplier tethered to the result of triangle for the next section onward in the diagonal axes.

2*6=12

2+12=14

12*2= 24

Trailing numbers through the X,Y squared orientation from the Diagonal Z axes orientation:

The sum of each pyramid for the X,Y squared location in question carry over and result in the sum of X,Y squared corner variables.


the sums of the outer X,Y squared and diagonal Z axes can be divided by 1.5 to give conclusive number results, for example:

Diagonal corners equal the sum of horizontal triangle main values divided by 1.5.

36/1.5 = 24
18/1.5 = 12
9/1.5 = 6

24/1.5 = 16
12/1.5 = 8
8/1.5 = 5.3333333 repeated infinitely.

6/1.5 = 4
4/1.5 = 2.6666666 repeated infinitely

16/1.5 = 10.6666666 repeated infinitely


*special note:

7/1.5 = 4.6666666 repeated infinitely

oh yeah, and a correction on the base mathematics.

3/1.5 = 2

I would try to read info off of Nand/NOR, CPU, Ram, and possibly RSX if i was able to. Remember, when injecting code like this, even a micro-millisecond counts.

Also, if you haven't already, connect to my hamachi server:

Warning: LAMERS WILL BE BANNED!

Network ID: Scalar-Ellipsis

PW: HamNCh33z


As for the math, any help is appreciated. Get Gobby and talk to me over hamachi and we'll get that set up.


BTW: Root equation for this = (0.5*3=1.5*2=3*2=6*2=12*3=36/6=6/2=3/2=1.5/3=0.5)

if this is properly designed and coordinated, we should ultimately be able to decrypt private keys through a chain. (which afaik hasn't been achieved at all yet, could be wrong).

Check out the Waninkoko possible 3.6x theory. He explains a boot process, which would be a series of obtaining a key to obtain the next.
Here is a good explanation from a developer named defyboy on the boot process:

Very good question, I also was curious about this matter originally and also could not locate any documents to clarify how this works. I am certainly not an expert on the matter but I think I have a decent understanding, let me explain what I know.

This is my current understanding of the boot order:
bootldr (Per-Console encrypted on flash, cannot be updated, has not yet been dumped)
lv0 (Not per console encrypted, but we do not have the public or private encryption keys currently)
metldr (Per-Console encrypted on flash, cannot be updated, has been dumped)
loaders (lv1ldr, isoldr are passed from lv0 into metldr).
From here the rest of the chain is loaded.

These are the points I understand about breaking the chain:
1) bootldr and metldr are stored in the asecure_loader region of the flash, is encrypted per console
2) bootldr and metldr, as far as we are aware, cannot be updated and never have been
3) 3.60 has changed lv0, since we cannot dump bootldr and get the private keys, we cannot decrypt the new lv0
4) now that all the loaders are packed within lv0, we cannot get the private keys to decrypt the rest of the firmware unless we dump lv0
5) Mathieulh has published a exploit for dual_nor and cell_reset that could possibly dump a large portion of the decrypted loaders
6) bootldr is run in a spu under isolation mode, aparently we are not able to run this more than once, this makes exploiting the bootldr process very difficult

Basically, to fully break the chain of trust, we need to exploit the bootldr process and dump it to get the public key for lv0. If we have the public key we could fully decrypt the firmware. If we are lucky, Sony will have used the sign fail on lv0, allowing us to also sign our own modified lv0, since bootldr is considered un-updateable, we would have completely broken current hardware.

I think this is the area we need to investigate:

+Initializes I/O

+fetches encrypted bootldr off NAND/NOR flash (at address 0xFC0000)

+Initializes RAM

+Loads bootldr into isolated spu (SPE0)

Also, we're not trying to inject code per-se, we're trying to monitor the sequence and run this cryptography through it in a side channel attack to keep the timing attack location open.

http://psx-scene.com/forums/f6/updat...process-87997/ (UPDATED - The CellBE Secure Boot Process)

I was having a chat with master737373 and he mentioned that Syscon would be an appropriate location to start because there's a JTAG port, and also because it's the boot process. I don't disagree either, but i think everything up to bootldr init should be looked at.


[22:38:35] << sure thnig, btw, check the thread
[22:38:42] << looks like bootldr is our target
[22:41:32] >> yup
[22:42:08] >> meaning...we need to physically inject the code either in the NAND/NOR or SYSCON
[22:42:32] << i'm willing to bet it's syscon, but i have no knowledge to back that up
[22:42:37] << just a gut feeling
[22:44:56] >> i would say syscon since it's what directly communicates with the southbridge, rsx, and cell. and after reading some more on it, it has a disabled jtag port... curious
[22:46:13] << is the port still there on the board?
[22:46:32] >> it's there, just disabled
[22:46:37] <<
[22:46:41] << curious indeed
[22:47:05] << you know, jtag was what ended up giving full system access to the 360
[22:47:14] << maybe you're onto something
[22:49:08] >> So, using the private keys to get the public keys?
[22:49:40] >> now with the syscon "There is external access by JTAG (Which appears to have been disabled after factory programming) and Serial"
[22:50:01] >> I'm just assuming it's been disabled via software
[22:50:16] << hmm, no readings out of it then?
[22:50:40] << they could've programmed the jtag on a hypervisor switch
[22:50:56] << which is triggered after initial boot or something
[22:51:02] << then they remove the jtag port
[22:51:13] << solder it up, w/e
[22:54:47] >> well, the jtag aread is still there, on the bottom of the board. the only problem is enabling it. if it IS programmed on a HV switch, then it should be able to get a hardware enabling per boot (in theory) and that'll be it because that's root access. But can't your algorithm also enable it, in some strange way?
[22:54:52] >> area*
[22:55:07] >> its physically on the syscon
[22:55:55] << okay, well what this algorithm would do is look for the lag gaps, then lattice through them at the same time with exponential equations
[22:56:00] << it would act kinda like a net
[22:56:28] << we should be able to see inside while it's open and read the private key
[22:56:40] << make no mistake, this is hacking and not just the ps3
[22:56:48] << this is the whole AES-256 standard

Btw, to add some context (<< is me) and (>> is Master737373)

*note: i didn't write all this, it's a collection of good insights from the now closed thread.

[Thecourier]

Afaik, he didn't prove anything, he just said it wouldn't work.

[uzishotz]

And he explained why it made perfect sense why it wouldn't work. Just admit it, U DONT KNOW JACK SHIT! ur just trying to build a name for yourself in this community and ur only building a bad one. so please just drop all this bull shit and GTFO!

[Thecourier]

You know what, you're totally right, i know jack **** about hacking the ps3. If you read ANYTHING i posted, it's about attacking AES-256 completely, if we're able to do that, any protection sony has on the ps3 means ****all. Thank you, have a nice day! I'll not be turning this one into a flamewar. You keep waiting on him to release something, I'm working on my own.

[amp2006]

ok uzi thats it you will get an infraction for your bad words .i dont care if its true or not but you dont have right to say all those bad words i already deleted two post of you trolling so you got your chance .

[uzishotz]

what ever i dont even care lool, this guy is getting nowhere and im sorry to say this but dont let him get your hopes up everyone cause he is just wasting his time.

Ban me if you will but I tell the truth to the community cause thats what I think they deserve

[Thecourier]

If I'm wasting my time, provide a better hope for it or something with a better chance of working. That's as far as I'm going to venture off topic from here out.

As far as I'm concerned, cracking AES-256 isn't a waste of time, even if the immediate uses aren't applicable on ps3.

[uzishotz]

well this isnt gonna do anything. Mathieulh explained every reason as to why it wouldn't work yet u still continue with the crap.

[Thecourier]

Well I'm not just a one trick pony dude, sorry. Sometimes you need to do other things to accomplish the main focus. This may not do anything at first, but that doesn't matter, it's the long term result bro. I've got no issue with you.

Help me make it better if you think it's flawed, give some better advice. Be productive, destruction is only holding this community back.

*Edit: Remember, it's a community when everyone works together to try and make something work. It's an oligarchy when everyone works together to say how it won't.

[andonevris]

I didn't understand a word of that, but it still sounds great!