Coding Horrors: You can gather all your technical debt into one easy framework!

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Coding Horrors: You can gather all your technical debt into one easy framework!

«‹›1503 »

Malloc Voidstar: May 7, 2007; Fuck the cowboys. Unf. Fuck em hard.

OUYA Inc posted:

The receipt decryption happens inside the application to help prevent hacking. By moving the decryption into each application there is no "one piece of code" a hacker can attack to break encryption for all applications. In the future, we will encourage developers to avoid using the decryptReceiptResponse method. They will need to move the method into their application, and perturb what it does slightly (changing for-loops to while-loops, and so forth) to help make things even more secure.
Currently, the ODK is under heavy development, so the helper method will assist in insulating you from our "under-the-hood" changes.

# ? Apr 4, 2013 06:26

Adbot: ADBOT LOVES YOU

# ? May 17, 2024 14:47

pigdog: Apr 23, 2004; by Smythe

Aleksei Vasiliev posted:

OUYA Inc

That is a good one.

# ? Apr 4, 2013 07:24

dis astranagant: Dec 14, 2006

I'm honestly speechless as to just what the could possibly have thought any of that accomplished.

# ? Apr 4, 2013 07:27

Bunny Cuddlin: Dec 12, 2004

Aleksei Vasiliev posted:

oh come on, are there any actual software developers working for that project

# ? Apr 4, 2013 07:30

Jewel: May 2, 2009

Nope.

Also I don't think it was posted here but the OUYA also doesn't force any confirmation on in-app billing. Completely silent. All up to the app itself to make a confirmation menu. And you're forced to add your billing info into the machine when you start it up for the first time. :allears:

Edit: vvv I think so? I think that was the point where people finally started digging into the code-side of OUYA and laughing forever.

Jewel fucked around with this message at 07:42 on Apr 4, 2013

# ? Apr 4, 2013 07:36

pseudorandom name: May 6, 2007

Did the bit about the Ouya's IAP API ignoring the testing attribute after the app gets released to the marketplace ever get posted in this thread?

# ? Apr 4, 2013 07:40

Bunny Cuddlin: Dec 12, 2004

Jewel posted:

Nope.

Also I don't think it was posted here but the OUYA also doesn't force any confirmation on in-app billing. Completely silent. All up to the app itself to make a confirmation menu. And you're forced to add your billing info into the machine when you start it up for the first time.

Open Source Video Games

# ? Apr 4, 2013 07:41

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

dis astranagant posted:

I'm honestly speechless as to just what the could possibly have thought any of that accomplished.

It's pretty clearly an attempt to make the crypto code specifically not have a reliable address or layout in memory between different apps. Brainstorming on why that could matter:

1. If the device/kernel actually allows writable executable pages, then any code at a stable address would be relatively easy for an exploit to disable/alter/weaken. But that's mostly an argument for not having writable executable pages, or failing that, using one of the many well-known ways to make this less feasible as an attack vector.

2. Even if you don't have writable executable pages, then code at stable addresses can still be exploited for things like return-oriented programming. But it doesn't make sense to single out the crypto code as something to protect against this, and again, there are much better techniques for making ROP difficult.

3. An attacker with physical access might be able to use a debugging interface to compromise an app. That's slightly easier if you know where objects and code are in memory, but only very slightly.

And of course all of this only has any effect on cross-app exploits. If you're willing to write a exploit that just targets one app � and one might hope that most exploits will not be of system code, although that seems like a slim hope given what we've seen � this suggestion will have precisely zero effect.

tl;dr: they're worried about limiting the damage of an exploit and have no idea what they're doing.

# ? Apr 4, 2013 08:38

Jabor: Jul 16, 2010; #1 Loser at SpaceChem

rjmccall posted:

It's pretty clearly an attempt to make the crypto code specifically not have a reliable address or layout in memory between different apps. Brainstorming on why that could matter:

1. If the device/kernel actually allows writable executable pages, then any code at a stable address would be relatively easy for an exploit to disable/alter/weaken. But that's mostly an argument for not having writable executable pages, or failing that, using one of the many well-known ways to make this less feasible as an attack vector.

2. Even if you don't have writable executable pages, then code at stable addresses can still be exploited for things like return-oriented programming. But it doesn't make sense to single out the crypto code as something to protect against this, and again, there are much better techniques for making ROP difficult.

3. An attacker with physical access might be able to use a debugging interface to compromise an app. That's slightly easier if you know where objects and code are in memory, but only very slightly.

And of course all of this only has any effect on cross-app exploits. If you're willing to write a exploit that just targets one app — and one might hope that most exploits will not be of system code, although that seems like a slim hope given what we've seen — this suggestion will have precisely zero effect.

tl;dr: they're worried about limiting the damage of an exploit and have no idea what they're doing.

The "exploits" they appear to be worried about are people modifying apps to be able to use them for free instead of having to by them.

So yes it's pretty safe to assume they have no idea what they're doing.

# ? Apr 4, 2013 08:45

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

Jabor posted:

The "exploits" they appear to be worried about are people modifying apps to be able to use them for free instead of having to by them.

So yes it's pretty safe to assume they have no idea what they're doing.

Okay, yeah, I see. They are worried about somebody having a script which cracks an arbitrary app image, so they want the decrypt code to be at a different offset in the image (less important, because finding a specific blob of bytes in an app is still trivially scriptable) and to not be byte-for-byte identical, so that ideally it would take human intelligence to actually crack each individual app.

Of course, what will actually happen is that the universal crack � if it even attacks this way � will scan for close matches instead, because it's not like any other code in the program will look like the decrypt code anyway. Or any number of other approaches.

Do they really not sign app images?

# ? Apr 4, 2013 09:16

pseudorandom name: May 6, 2007

One of the Ouya's design goals was being end-user rootable.

The Google Play Licensing Service documentation has a similar discussion of taking their example code and modifying it for your own use, right before they tell you to run your apps through ProGuard.

# ? Apr 4, 2013 09:23

ymgve: Jan 2, 2004; Offensive Clock

The bigger problem is a design model that, as someone in YOSPOS put it, allows you to make a Mario clone that bills the user silently $1 for each ingame coin they collect.

# ? Apr 4, 2013 12:07

nexus6: Sep 2, 2011; If only you could see what I've seen with your eyes

Volmarias posted:

Spend two days "fixing" it that you actually spend on making other things with less visibility better.

Or updating your resume.

# ? Apr 4, 2013 13:22

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

Why do they think changing for-loops to while-loops will do anything?

# ? Apr 4, 2013 13:31

Jonnty: Aug 2, 2007; The enemy has become a flaming star!

Suspicious Dish posted:

Why do they think changing for-loops to while-loops will do anything?

At first, without knowing what they were talking about, I thought it was a clumsy way of saying they should do stuff in constant time to avoid timing attacks. Now I realise I was giving them far too much credit.

# ? Apr 4, 2013 13:35

LOOK I AM A TURTLE: May 22, 2003; "I'm actually a tortoise."; Grimey Drawer

Suspicious Dish posted:

Why do they think changing for-loops to while-loops will do anything?

I'm also curious to learn what they mean by "and so forth" in that same parenthetical. Should we also be changing if-statements to gotos?

# ? Apr 4, 2013 14:14

Space Kablooey: May 6, 2009

I took it to mean that you should change the crypto code they give you so it's different for every new app.

Let's say in the crypto code they give you there's the following snippet:

code:

if (foo > 1)
{

}

and then you can change that snippet to:

code:

if (!(foo <= 1))
{

}

so the crypto code is totally safer* now.

Space Kablooey fucked around with this message at 14:51 on Apr 4, 2013

# ? Apr 4, 2013 14:49

SavageMessiah: Jan 28, 2009; Emotionally drained and spookified; Toilet Rascal

Wouldn't the compiler optimize that down to the same code? Often it would be the same with while and for. What a bunch of morons.

# ? Apr 4, 2013 15:04

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

SavageMessiah posted:

Wouldn't the compiler optimize that down to the same code? Often it would be the same with while and for. What a bunch of morons.

# ? Apr 4, 2013 15:21

God of Mischief: Oct 22, 2010

Text changed because I can't remember what it was, but I do not think whoever coded this understands what a StringBuilder is for... (found in production code, of course)

code:

StringBuilder sb = new StringBuilder();
return sb.append("stuff " 
    + "more stuff "
    + "yet more stuff "
    + "seriously now?")
  .toString();

# ? Apr 4, 2013 15:44

Uziel: Jun 28, 2004; Ask me about losing 200lbs, and becoming the Viking God of W&W.

God of Mischief posted:

Text changed because I can't remember what it was, but I do not think whoever coded this understands what a StringBuilder is for... (found in production code, of course)
code:
StringBuilder sb = new StringBuilder();
return sb.append("stuff " 
    + "more stuff "
    + "yet more stuff "
    + "seriously now?")
  .toString();

Having done something similar myself in the past, I think that this is just a case of when you learn something new to you, everything looks like a nail as wield your new hammer. "I have to return strings? Let's build that string with a string builder!"

# ? Apr 4, 2013 15:55

pigdog: Apr 23, 2004; by Smythe

God of Mischief posted:

Text changed because I can't remember what it was, but I do not think whoever coded this understands what a StringBuilder is for... (found in production code, of course)
code:
StringBuilder sb = new StringBuilder();
return sb.append("stuff " 
    + "more stuff "
    + "yet more stuff "
    + "seriously now?")
  .toString();

IDEA can auto-fix these things... not that (with constant strings) there's any difference either way, IIRC.

# ? Apr 4, 2013 15:58

The Gripper: Sep 14, 2004; i am winner

SavageMessiah posted:

Wouldn't the compiler optimize that down to the same code? Often it would be the same with while and for. What a bunch of morons.

Yep, it'll generate the exact same bytecode for if (foo > 1) and if (!(foo <=1 )) (a single jle op I think). I really have no idea what they were thinking when they wrote that unless they honestly expect people to roll their own crypto by changing things in a more invasive way.

# ? Apr 4, 2013 16:12

mobby_6kl: Aug 9, 2009; by Fluffdaddy

C++ code:

	if (a > '5')
010C1400  cmp         dword ptr [a],35h  
010C1404  jle         main+4Dh (010C141Dh)  
....
	if (!(a <= '5'))
010C141D  cmp         dword ptr [a],35h  
010C1421  jle         main+6Ah (010C143Ah)

Without optimizations, the compiler is too literal in translating the loops, but...

code:

	for (i = 0; i < 5; i++)
008A1034  xor         esi,esi  
		printf("Line %d\n", i);
008A1036  push        esi  
008A1037  push        8A6010h  
008A103C  call        edi  
008A103E  inc         esi  
008A103F  add         esp,8  
008A1042  cmp         esi,5  
008A1045  jl          main+26h (08A1036h)  

-----------------------------------------
	n =0;
008A1047  xor         esi,esi  
008A1049  lea         esp,[esp]  
	while (n<5) {
		printf("Also line %d\n", n);
008A1050  push        esi  
	while (n<5) {
		printf("Also line %d\n", n);
008A1051  push        8A601Ch  
008A1056  call        edi  
		n++;
008A1058  inc         esi  
008A1059  add         esp,8  
008A105C  cmp         esi,5  
008A105F  jl          main+40h (08A1050h)  
	}

Not sure what kind of black magic lea is performing there, but other than that, :downsbravo:

# ? Apr 4, 2013 19:03

Blotto Skorzany: Nov 7, 2008; He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

mobby_6kl posted:

Not sure what kind of black magic lea is performing there, but other than that,

As an aside, MSVC and ICC seem to be pretty sanguine on lea in general, and often replace general arithmetic muls and adds with it (in addition to the pure addressing stuff that a non-specialist human would tend to use it for).

e: clarity

Blotto Skorzany fucked around with this message at 19:12 on Apr 4, 2013

# ? Apr 4, 2013 19:08

hobbesmaster: Jan 28, 2008

That lea is a noop isn't it?

# ? Apr 4, 2013 19:10

Zhentar: Sep 28, 2003; Brilliant Master Genius

The lea is a 3 byte NOP, used to align the loop (apparently onto a 16-byte boundary, which it seems can be a significant optimization for some processor architectures).

# ? Apr 4, 2013 19:10

ExcessBLarg!: Sep 1, 2001

Otto Skorzeny posted:

As an aside, MSVC and ICC seem to be pretty sanguine on lea in general, and often replace general arithmetic muls and adds with it

This may be done partly because lea doesn't set FLAGS as a side-effect, which can be helpful for instruction scheduling.

# ? Apr 4, 2013 19:16

trex eaterofcadrs: Jun 17, 2005; My lack of understanding is only exceeded by my lack of concern.

Zhentar posted:

The lea is a 3 byte NOP, used to align the loop (apparently onto a 16-byte boundary, which it seems can be a significant optimization for some processor architectures).

Why wouldn't the compiler just emit nop, nop, nop? Just to be hipster or something?

# ? Apr 4, 2013 19:40

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

Yep, not setting FLAGS is a major part of it; also, addressing-mode calculations also sometimes have their own functional units. But in this case, yes, it's a no-op being used to align the loop, which is a surprisingly effective optimization � effective enough that compilers will generally always try to align loops, in contrast to the usual worry about balancing code size.

ETA: And you use longer nops instead of multiple shorter because there's overhead in interpreting and issuing instructions, even nops.

# ? Apr 4, 2013 19:41

Opinion Haver: Apr 9, 2007

trex eaterofcadrs posted:

Why wouldn't the compiler just emit nop, nop, nop? Just to be hipster or something?

It might be faster on that architecture.

# ? Apr 4, 2013 19:43

trex eaterofcadrs: Jun 17, 2005; My lack of understanding is only exceeded by my lack of concern.

yaoi prophet posted:

It might be faster on that architecture.

I wonder if it has a negative effect on code cache. I don't know enough about instruction optimization any more

# ? Apr 4, 2013 19:44

Bhaal: Jul 13, 2001; I ain't going down alone; Dr. Infant, MD

Aleksei Vasiliev posted:

I had to check the link to see whether you added the emphasis on perturb or if they did. That is absolutely the best part.

"On this fairly critical security measure, we've moved the responsibility to developers so they can... do... welllll, stuff."

# ? Apr 4, 2013 20:42

evensevenone: May 12, 2001; Glass is a solid.

It's obviously so if there's a security problem, they can blame the developers.

# ? Apr 4, 2013 21:11

Goat Bastard: Oct 20, 2004

pigdog posted:

IDEA can auto-fix these things... not that (with constant strings) there's any difference either way, IIRC.

There's no difference in Java with variable strings these days either. Since 1.5 or 1.6 "string" + someString + "string" is shorthand for new StringBuilder("string").append(someString).append("string").toString(); instead of .concat() like it used to be

Goat Bastard fucked around with this message at 21:29 on Apr 4, 2013

# ? Apr 4, 2013 21:24

ymgve: Jan 2, 2004; Offensive Clock

But I hope Java is smart enough to recognize concatenation of multiple constant strings as one single constant?

# ? Apr 4, 2013 21:38

Munkeymon: Aug 14, 2003; Motherfucker's got an
armor-piercing crowbar! Rigoddamndicu𝜆ous.

evensevenone posted:

It's obviously so if there's a security problem, they can blame the developers.

Also this https://www.eff.org/deeplinks/2013/04/app-developers-lodsys-back

One lawsuit would probably scuttle the whole thing.

# ? Apr 4, 2013 21:41

Zhentar: Sep 28, 2003; Brilliant Master Genius

trex eaterofcadrs posted:

I wonder if it has a negative effect on code cache.

If you're caching the non-decoded instructions, then it doesn't matter, because they're the same size. Past that... the CPU architects are well aware that lea esp, [esp] (or equivalent) is a popular 3 byte NOP, so they're not going to handle it any less efficiently than NOP NOP NOP.

Fun fact: the NOP opcode happens to be exactly the same as the opcode for xchg eax, eax.

# ? Apr 4, 2013 21:43

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

I wonder if Intel publishes "here's nops for all byte sizes that matter" which their processors will try to handle faster than other nop instructions.

# ? Apr 4, 2013 21:55

Adbot: ADBOT LOVES YOU

# ? May 17, 2024 14:47

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

ymgve posted:

But I hope Java is smart enough to recognize concatenation of multiple constant strings as one single constant?

As I read the language spec, Java is actually required to constant-fold concatenations that involve only constant strings and primitives, so "abc" + 4 * 5 + "def" is required to be treated exactly like "abc20def".

If string concatenation in Java ever used String.concat, it was a very long time ago; Java was using StringBuffer for it at least in 1.1. It started using StringBuilder in 1.5 (when targeting 1.5 or higher).

# ? Apr 4, 2013 22:26

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Coding Horrors: You can gather all your technical debt into one easy framework!

«‹›1503 »