Omnimaga

Calculator Community => TI Calculators => ASM => Topic started by: thepenguin77 on September 18, 2011, 01:27:11 am

Title: The worst TI code I've ever seen
Post by: thepenguin77 on September 18, 2011, 01:27:11 am
A while ago when I was making my boot code 1.03 exploit, I was looking through the app security code when I found absolutely horrendous code. The whole system of app trials appears to be written by someone who has been programming z80 for less than a week. The worst part though is that this person was assigned to write code that protects paid apps and is run on a privileged page. But of all the app trials code, this one routine just sticks out as the worst TI code I've ever seen.

Here it is in it's entirety:
Code: [Select]
transformA:
push bc
ld c, 11h
sub c
jp nc, loc_4F03
or a
adc a, c
cp 0
jr z, loc_4F03
cp 1
jr z, loc_4F03
ld b, a
dec b
ld a, 2

loc_4EFA:
sla a
djnz loc_4EFA
ld b, 1
sub b
jr loc_4F05

loc_4F03:
ld a, 0

loc_4F05:
pop bc
ret

First off, what is the purpose of this routine? It is a really complicated way to calculate the number of trials an app should have, I'll show the code that calls it at the end. But let's try to figure out what this routine does. (To be honest, I didn't figure it out until just now.)

The expected results are given by this table:
if A = 0-16  result = 2^A - 1
if A >= 17  result = 0

However, since the result is returned in A, the real table is:
if A = 0-8  result = 2^A - 1
if A >= 9-16  result = 255
if A >= 17  result = 0


Now, let's break this down and see where they went so wrong.

Code: [Select]
transformA:
push bc
ld c, 11h
sub c
jp nc, loc_4F03
or a
adc a, c

When you see this, your expected response should be "wtf." What are they doing? First off, why don't they just do CP 11h \ JR NC, loc_4F03? Then, why do they use ADC? I honestly believe the person who wrote this code didn't know that ADD existed.

Code: [Select]
cp 0
jr z, loc_4F03
cp 1
jr z, loc_4F03
ld b, a
dec b
ld a, 2

Again, horrible. CP 0 is a no. CP 1 is acceptable, but DEC A is preferred. And would you look at that, they DEC A anyways!

Code: [Select]
loc_4EFA:
sla a
djnz loc_4EFA
ld b, 1
sub b
jr loc_4F05

They actually did the loop correct, which is a surprise. But what on earth are they doing at the end. Again, I don't think this programmer knew that you are allowed to do actions to A, like ADD and SUB. But the worst part is that they could have used DEC A, but what really sets this apart is that they have already used DEC once! It's not like they didn't know it existed.

Code: [Select]
loc_4F03:
ld a, 0

loc_4F05:
pop bc
ret

They finally wrap it up with this. XOR A would be preferred, but the programmer probably didn't know what XOR does.

For comparison, here's how the routine should look:
Code: [Select]
transformA:
or a
ret z
cp 11h
jr c, notOver17
xor a
ret
notOver17:
ld b, a ;b is trash anyways
ld a, 1
shiftLoop:
add a, a
djnz shiftLoop
dec a
ret

Ok, but it doesn't stop there, here's the code that calls it.

Code: [Select]
call getCertByte

loc_4E55:
push af
ld b, 9
sub b
jr c, loc_4E6B
pop af
ld b, 8
sub b
call transfromA
ld d, a
ld a, 8
call transformA
ld e, a
jr loc_4E72

loc_4E6B:
ld d, 0
pop af
call transformA
ld e, a

loc_4E72:

It should be noted that LD A, 8 \ CALL transformA is the equivalent of LD A, 255.


Well, I hope you enjoyed that. Hopefully this will help to explain the dislike of TI that the more advanced assembly programmers share. It is code like this that causes Err:Version and Err:Bad Address, and the OS is full of it.

Edit:
   Hey, what an awesome post to be number 1000.
Title: Re: The worst TI code I've ever seen
Post by: meishe91 on September 18, 2011, 01:43:53 am
Oh how I wish I knew Assembly...
Title: Re: The worst TI code I've ever seen
Post by: BrandonW on September 18, 2011, 01:50:19 am
Yeah, it's pretty obvious that the security code was written by one or more other people, probably with a stronger background in security than Z80 coding.

I've gone nuts more than a few times over disassembling some of this stuff, but I started to realize that perhaps I'm nitpicking a little bit. We're heavily analyzing code that was probably done in a hurry 15 years ago.
Title: Re: The worst TI code I've ever seen
Post by: XVicarious on September 18, 2011, 01:50:44 am
Same lol. I do understand it to a point. I know how much we despise TI for what they do to the community, but some of our best ASM programmers should apply to TI and maybe fix TI-OS lol. Updates for all of the z80 calcs. Even the TI-83 lol.
Title: Re: The worst TI code I've ever seen
Post by: shmibs on September 18, 2011, 02:27:15 am
wows, even i can see what's going wrong there.
brandonw does have a point, but they should have at least looked back through it afterwards and cleaned it up.
Title: Re: The worst TI code I've ever seen
Post by: NanoWar on September 18, 2011, 11:14:33 am
It's not a bug, it's just coded by a newbie. That doesnt make this any better though...
Title: Re: The worst TI code I've ever seen
Post by: p2 on September 18, 2011, 12:16:32 pm
Er...
It's not really about the code (which I don't understand - I don't know ASM)
But what do you mean with paid apps??
So It should protect apps for which you've paid??? Why should I pay for an app? I can get everything for free, I want to have!!
And it should protect the apps. But, of what?? Of archieve-clears??? Of editing them???
Title: Re: The worst TI code I've ever seen
Post by: calc84maniac on September 18, 2011, 02:00:32 pm
Another thing, sla a should probably be add a,a (and like you said, the programmer probably didn't know about add :P)
Title: Re: The worst TI code I've ever seen
Post by: sqrt(Time) on September 18, 2011, 02:01:11 pm
TI originally designed a whole system for app signing, where you could either sign it with a free key and distribute it freely... or you could sell your app, but in order to do that you would need to buy an a key to sign it with from TI. Frankly, I don't think TI ever sold ever more than 2 of those keys tops...
As you may have deduced, everyone here uses the free key. (And yes, you CAN get everything good for free. ^_^)
Title: Re: The worst TI code I've ever seen
Post by: Xeda112358 on September 18, 2011, 02:06:43 pm
It is almost scary how good some of the programmers are, here. I think that if they all designed an OS, it would be ridiculously amazing and more stable (though the TI-OS is pretty stable).
Title: Re: The worst TI code I've ever seen
Post by: thepenguin77 on September 18, 2011, 02:23:20 pm
Another thing, sla a should probably be add a,a (and like you said, the programmer probably didn't know about add :P)

Good call ;)
Title: Re: The worst TI code I've ever seen
Post by: Hot_Dog on September 18, 2011, 04:00:44 pm
Most of the stuff here is stuff anyone would do if they had little experience, but I feel that SUB instead of CP is unforgivable, especially since SUB destroys whatever was inside of register A
Title: Re: The worst TI code I've ever seen
Post by: ben_g on September 18, 2011, 04:03:36 pm
Most of the stuff here is stuff anyone would do if they had little experience,...
but still: only TI does 'or   a \ adc   a, c'. Everyone that knows what a z80 is uses 'add a, c'.
Title: Re: The worst TI code I've ever seen
Post by: thepenguin77 on September 18, 2011, 04:12:09 pm
Most of the stuff here is stuff anyone would do if they had little experience,...
but still: only TI does 'or   a \ adc   a, c'. Everyone that knows what a z80 is uses 'add a, c'.

Don't forget about LD B, 1 \ SUB B.
Title: Re: The worst TI code I've ever seen
Post by: ben_g on September 18, 2011, 04:24:59 pm
I often do that too. I sometimes forget you can do it directely.
Title: Re: The worst TI code I've ever seen
Post by: ralphdspam on September 18, 2011, 04:59:04 pm
Code: [Select]
ld b, 9 ;Really?  You have to load 9 into B to subtract it?  
sub b
jr c, loc_4E6B
pop af
ld b, 8  ;Ok, so you already have 9 in b.  The logical thing to do now would be dec b.
sub b ;Oh, but no, you do the same bloody thing again!!!
;I forgot to mention that this code is missing a ld a,a.  :P


As for the add and adc, there seem to be quite a few programmers (not here, of course) who misused the add instruction.  For example, the code for the Pac Man machine (yes, it was a z80 too) has a lot of "ccf \ add b".  They still have no excuse.
Title: Re: The worst TI code I've ever seen
Post by: thepenguin77 on September 18, 2011, 05:09:09 pm
As for the add and adc, there seem to be quite a few programmers (not here, of course) who misused the add instruction.  For example, the code for the Pac Man machine (yes, it was a z80 too.) has a lot of "ccf \ add b".  They still have no excuse.

Actually, you'll notice that instead of doing the stupid subtraction with B, they should have just done CP 9 since they restore A :P
Title: Re: The worst TI code I've ever seen
Post by: ralphdspam on September 18, 2011, 05:13:39 pm
Actually, you'll notice that instead of doing the stupid subtraction with B, they should have just done CP 9 since they restore A :P
Oh, lol.  I didn't notice the push af in the beginning.  
Wow...
...and they use "cp 0" earlier even though they use "or a" before.
It's like they have a memory span of a goldfish or something.  This is absolutely inexcusable and yet somewhat hilarious.  
Title: Re: The worst TI code I've ever seen
Post by: Freyaday on September 18, 2011, 06:22:22 pm
I know nothing about ASM, and yet I still feel that faint sense of revulsion.
Spoiler For Unnecessary Simile:
It's like when I read the CodeSODs on TDWTF. I don't know the languages themselves, but I know enough to still feel horrified (sometimes)
It is almost scary how good some of the programmers are, here. I think that if they all designed an OS, it would be ridiculously amazing and more stable (though the TI-OS is pretty stable).
Agreed.
Title: Re: The worst TI code I've ever seen
Post by: NanoWar on September 19, 2011, 01:44:17 pm
Writing or a instead of cp 0 doesnt make a good program. I use cp 0 for better readability. Compilers should take care of that, actually.
Title: Re: The worst TI code I've ever seen
Post by: calc84maniac on September 19, 2011, 01:47:41 pm
For most z80 programmers, or a is very readable, as is xor a. Assemblers shouldn't automatically optimize because sometimes you need to use "unoptimized" code on purpose (such as ld a,0 to preserve flags or to provide a byte for SMC)
Title: Re: The worst TI code I've ever seen
Post by: tangrs on September 30, 2011, 05:14:07 am
Maybe it's deliberately obfuscated code?
Title: Re: The worst TI code I've ever seen
Post by: AngelFish on September 30, 2011, 10:12:10 am
The problem is that it's not obfuscated :P
Title: Re: The worst TI code I've ever seen
Post by: Freyaday on September 30, 2011, 10:12:59 am
Maybe it's deliberately obfuscated code?
Perhaps, but...
Actually, it seems just like TI to try and "protect" their code with something this stupid and heinous, but they don't seem smart enough to deliberately write bad code. I think they just produce things that make you give up all hope unintentionally. Or....
Title: Re: The worst TI code I've ever seen
Post by: Yeong on September 30, 2011, 11:50:55 am
Maybe it's deliberately obfuscated code?
Perhaps, but...
Actually, it seems just like TI to try and "protect" their code with something this stupid and heinous, but they don't seem smart enough to deliberately write bad code. I think they just produce things that make you give up all hope unintentionally. Or....
or make something called TI-NOspine that costs $230 that 'protects' it from all hardware hacks and development :P
Title: Re: The worst TI code I've ever seen
Post by: ralphdspam on October 03, 2011, 03:04:14 am
Maybe it's deliberately obfuscated code?
They're shooting themselves in their feet, then.  :P
It's getting the code more attention than intended.
Title: Re: The worst TI code I've ever seen
Post by: willrandship on October 03, 2011, 03:27:33 am
Well, if you're writing on the asm level optimizations require a certain amount of interpretation, which an assembler is likely to miss, but a programmer should understand fairly easily. After all, they wrote the initial code.

*Auto-Optimizing C is simpler, since the commands arbitrate the registers and other hardware concerns into the stack.