FORUMS
Remove All Ads from XDA

[UTILITY] Lua 5.1 tools: compiler, decompiler, snippets & extendable lua.dll with SDK

1,061 posts
Thanks Meter: 877
 
Post Reply Email Thread
5th March 2009, 08:31 PM |#191  
sztupy's Avatar
OP Inactive Recognized Developer
Flag London
Thanks Meter: 877
 
Donate to Me
More
Decompiling tutorial part 3

So, we have cleaned the output, and running compare will not output a compilation error, but a comparison of the two scripts. Let's continue from here.

What you love:

Code:
Main block:
Same
What you hate:

Code:
Function 3:
  1> 11 [-]: GETGLOBAL R1 K0        ; R1 := PeopleListView
  ...
And if you only get outputs from the first type, then you are very very happy

Now, let's start fixing the output.
I always look at the first bug:

Code:
Function 3:
  1> 11 [-]: GETGLOBAL R1 K0        ; R1 := PeopleListView
  2> 11 [-]: GETGLOBAL R0 K0        ; R0 := PeopleListView
Compare will always print out the differences in the two files. odd lines will be from the original, even lines will be from the decompiled script. Let's look at the usual bugs.

In the previous code output you can clearly see, that in the original PeopleListView is assigned to R1, but in out script it's assigned to R0. What does this mean? LOCALS! Yep, you have to declare something as a local in function #3 (which is the fourth(!) function, never forget!) And it's around opcode number 11, which is around the beginning of the file. To fix it you can either search for the string "PeopleListView" around the beginning of function 4, and declare something BEFORE that as a local. If you don't know what to declare as local, then look at the opcode line 10 (or 9, or something), and declare that as local.

For example in our example the original line was:

Code:
   if PeopleListView:GetLayout() == nil then
      return 
   end
   if PeopleListView:GetGenerator() == nil then
      return 
   end
I added some comments:

Code:
   -- this is opcode number 7. Here the disassembly output is:
   -- 7 [-]: CALL      R0 2 2       ; R0 := R0(R1)
   -- this is where PeopleListView:GetLayout() was declared as a local
   if PeopleListView:GetLayout() == nil then
      return 
   end
   -- this is opcode number 11. Here is the PeopleListView that is shown in the
   -- disassembly output 
   if PeopleListView:GetGenerator() == nil then
      return 
   end
The fixed output is:
Code:
   local l_4_0 = PeopleListView:GetLayout()
   if l_4_0 == nil then
      return 
   end
   if PeopleListView:GetGenerator() == nil then
      return 
   end
 
 
5th March 2009, 08:33 PM |#192  
sztupy's Avatar
OP Inactive Recognized Developer
Flag London
Thanks Meter: 877
 
Donate to Me
More
Decompiling tutorial part 4

The other usual bug is the following:

Code:
  1> 11 [-]: GETGLOBAL R1 K5        ; R1 := ContactObj
  2> 11 [-]: GETGLOBAL R1 K5        ; R1 := MyFavesUtilityObj
Here, in the original ContactObj is first, but in our script MyFavesUtilityObj is first. Lua will put the constants in the compiled output the same order it encounters them in the script. What could the previus bug mean?

Of course LOCALS!

Let's look at the script:

Code:
MyFavesUtilityObj:IsMyFavesContactyIDForLua(ContactObj.ContactList:GetOidStr(l_8_0 + 1))
As you can see here is a function call, which has one parameter. And look at it. In out script MyFavesUtilityObj comes first, but in the original output ContactObj should come first.

How to fix? Easy:

Code:
local cobj = ContactObj.ContactList:GetOidStr(l_8_0 + 1)
MyFavesUtilityObj:IsMyFavesContactyIDForLua(cobj)
As you can see, now ContactObj is the first thing it will encounter and not MyFavesUtilityObj!

There is one more bug which is usual:

Code:
  1>  6 [-]: LE        0 K2 R0      ; if 0 > R0 then PC := 69
  2>  6 [-]: LE        0 K2 R0      ; if 0 > R0 then PC := 68
  1>  7 [-]: JMP       69
  2>  7 [-]: JMP       68
  1>  9 [-]: EQ        0 R1 K4      ; if R1 != 1 then PC := 30
  2>  9 [-]: EQ        0 R1 K4      ; if R1 != 1 then PC := 29
  1> 10 [-]: JMP       30
  2> 10 [-]: JMP       29
CONDITIONALS!

99 out of 100 cases you will HATE them!

Usually if the only difference between the original and the decompiled script is the location where they jump (the PC:=xxx part) then don't care about them, unless you have fixed the rest of the script (I mean the locals). If there are only conditional statements left, then you will have a hard time guessing how this have to be done. Usually this means the structure of the conditionals are not right. For example instead of

Code:
 if blah then
   if blah then
     blah
   else
     blah
   end
 end
you have to put:

Code:
 if blah then
   if blah then
     blah
   end
 else
   blah
 end
And similar. Use common sense in these cases. Usually if you read the script and guess about what it does you will know how to fix these issues. In other cases the disassembly output might help, because it will show you where the jumps are. This is the part of the decompilation process which involves the most thinking usually. But after a while this part gets easy as well
5th March 2009, 08:55 PM |#193  
sztupy's Avatar
OP Inactive Recognized Developer
Flag London
Thanks Meter: 877
 
Donate to Me
More
Decompiling tutorial part 5

Here are two incorrectly decompiled scripts to play with. They doesn't have too much bugs in them, but show the usual errors one have to fix in order to get a fully decompiled script, so they are good for testing the skills you've learned with the previous tutorials I didn't touch any of them, so if you manage to succesfully decompile them, you can say that you've already decompiled a script yourselves... all alone

I didn't decompile them yet, so if you want to help me out, you might try to do them yourselves, before I get to them
Attached Files
File Type: zip play.zip - [Click for QR Code] (12.3 KB, 20 views)
6th March 2009, 05:22 PM |#194  
sztupy's Avatar
OP Inactive Recognized Developer
Flag London
Thanks Meter: 877
 
Donate to Me
More
305

New additions:
  1. 4 embedded scripts
  2. citypicker
  3. simpledialogscript
  4. stock_chart
  5. stock_setting
  6. people/contactobject
  7. people/contactpickerallscript
  8. people/contactpickerscript
  9. people/favoritesetting
  10. people/peopledetailselectnumber
  11. people/peopledialogbase
  12. people/peoplefavoriteglobal
  13. people/peopleselectcontactscript
  14. internetportal/bookmarkedit
  15. internetportal/internetpush_frequencysettings
Attached Files
File Type: zip touchpro2_manila3d_declua.zip - [Click for QR Code] (883.5 KB, 18 views)
6th March 2009, 10:15 PM |#195  
smotrs's Avatar
Senior Member
Flag So. Calif.
Thanks Meter: 0
 
More
Here's a question, why does the disassembler swap the == and ~= relational operators?

For instance, the disassembled output shows the following,
Code:
  2 [-]: EQ        0 R2 K1      ; if R2 != "windowsmobile" then PC := 12
but the decompiled output shows the same line like this,
Code:
   if l_1_2 == "windowsmobile" then
6th March 2009, 10:22 PM |#196  
smotrs's Avatar
Senior Member
Flag So. Calif.
Thanks Meter: 0
 
More
Here's another question. Why are the -f options in luadec and compare different values?

For instance, if I run a compare like this,
Code:
compare -f 0 1f3be060_manila_1583A.luac f3be060_manila_1583A.luac.lua
I have to run the following to get the same function with luadec,
Code:
luadec -f 1 1f3be060_manila_1583A.luac
one is using -f 0 the other -f 1 which is confusing.
6th March 2009, 11:14 PM |#197  
sztupy's Avatar
OP Inactive Recognized Developer
Flag London
Thanks Meter: 877
 
Donate to Me
More
Quote:
Originally Posted by smotrs

Here's a question, why does the disassembler swap the == and ~= relational operators?

For instance, the disassembled output shows the following,

Code:
  2 [-]: EQ        0 R2 K1      ; if R2 != "windowsmobile" then PC := 12
but the decompiled output shows the same line like this,
Code:
   if l_1_2 == "windowsmobile" then

The VM of lua is not structural. It goes from top to bottom, and if it encounters a JMP operator it will jump to the specified opcode. What this means that if it encounters something like

Code:
if blah then
end
then if blah is TRUE then it does nothing, and this is the right thing to do, because if TRUE, then you want to run the things following the if. But, if blah is FALSE then you have to jump through the hole sequence between the "if" and the "end" That's why the disassembled output shows (usually) the inverse what you have to write (it shows when to jump, and not when not to jump).

This is confusing a lot of times unfortunately, and there are a lot of bugs involving this too (this is mostly why the decompiler fails to decompile complex conditionals with lots of 'and', 'or' and 'elseif' parts... Unfortunately that part of the decompiler is not clear to me, the original code of luadec had no comments, and it had a very unreadable code)
6th March 2009, 11:20 PM |#198  
sztupy's Avatar
OP Inactive Recognized Developer
Flag London
Thanks Meter: 877
 
Donate to Me
More
Quote:
Originally Posted by smotrs

Here's another question. Why are the -f options in luadec and compare different values?

For instance, if I run a compare like this,

Code:
compare -f 0 1f3be060_manila_1583A.luac f3be060_manila_1583A.luac.lua
I have to run the following to get the same function with luadec,
Code:
luadec -f 1 1f3be060_manila_1583A.luac
one is using -f 0 the other -f 1 which is confusing.

Yes I know about that... this is unfortunately because luadisasm is 0 based, but luadec is 1 based. Half a while during the decomp I thought I might change this, but I got used to this anomaly so much I was confused after I did the changes... After I finish this whole decomping stuff I might correct this glitch...

Btw I never use the -f option of compare, that was only added so luadecguess could compare by function too. I usually get a good looking output with all the functions, correct it, so it compiles, then run compare without any fancy parameters, and press CTRL+C after it outputs some errors. Then I correct the errors, run compare again, CTRL+C, etc. until compare says "same" for everything.
7th March 2009, 08:06 PM |#199  
sztupy's Avatar
OP Inactive Recognized Developer
Flag London
Thanks Meter: 877
 
Donate to Me
More
LuaDec 0.7
Hi!

LuaDec 0.7 released.

This release contains a major bugfix considering OP_TFORLOOP fucntionality and conditional handling as well. I hope the changes I made in the conditional handling won't break anything that worked, but it shouldn't (actually it should make decompiling more error-free). A lot of decompilation erros and crashes were caused by these bugs, but now they should be gone...

I'm on EDGE currentyl so I can only release the modified file, will upload the whole package on monday.
Attached Files
File Type: zip luadec.zip - [Click for QR Code] (59.6 KB, 26 views)
7th March 2009, 08:36 PM |#200  
smotrs's Avatar
Senior Member
Flag So. Calif.
Thanks Meter: 0
 
More
Can you think of any reason why luadec (version 6 and now 7) with the -l option wouldn't output anything?

I tried it with and without the -l option. With the -l option just prints the following,
Code:
C:\Documents and Settings\user1\My Documents\My Software\Mobile Software\lua51_tf3d_beta_6>luadec -l ;;0,11,32;;0,17,38;;;;;;;5;;0,3,6,16,26;0,34;14,35;;;;;;;49,100,221;;0,0,223;;;;21,29;;;;;;;;;;;;;;;19;;0,0,5;8;;;;; .\27a13690_hd\27a13690_manila.luac
-- Decompiled using luadec 0.7 by sztupy (http://winmo.sztupy.hu)
-- Command line was: -l ;;0,11,32;;0,17,38;;;;;;;5;;0,3,6,16,26;0,34;14,35;;;;;;;49,100,221;;0,0,223;;;;21,29;;;;;;;;;;;;;;;19;;0,0,5;8;;;;; .\27a13690_hd\27a13690_manila.luac
without the -l it outputs the decompile fine, but not as helpful.

Also, I tried it with the version 5 and it works fine with the -l option. So I re-downloaded version 6 tried it again and installed the version 7 both with the same results when it comes to the -l option.
7th March 2009, 08:47 PM |#201  
sztupy's Avatar
OP Inactive Recognized Developer
Flag London
Thanks Meter: 877
 
Donate to Me
More
Quote:
Originally Posted by smotrs

Can you think of any reason why luadec (version 6 and now 7) with the -l option wouldn't output anything?

I tried it with and without the -l option. With the -l option just prints the following,

Code:
C:\Documents and Settings\user1\My Documents\My Software\Mobile Software\lua51_tf3d_beta_6>luadec -l ;;0,11,32;;0,17,38;;;;;;;5;;0,3,6,16,26;0,34;14,35;;;;;;;49,100,221;;0,0,223;;;;21,29;;;;;;;;;;;;;;;19;;0,0,5;8;;;;; .\27a13690_hd\27a13690_manila.luac
-- Decompiled using luadec 0.7 by sztupy (http://winmo.sztupy.hu)
-- Command line was: -l ;;0,11,32;;0,17,38;;;;;;;5;;0,3,6,16,26;0,34;14,35;;;;;;;49,100,221;;0,0,223;;;;21,29;;;;;;;;;;;;;;;19;;0,0,5;8;;;;; .\27a13690_hd\27a13690_manila.luac
without the -l it outputs the decompile fine, but not as helpful.

Also, I tried it with the version 5 and it works fine with the -l option. So I re-downloaded version 6 tried it again and installed the version 7 both with the same results when it comes to the -l option.

It looks like it crashed. Does it output anything with -d option set?
Post Reply Subscribe to Thread

Tags
lua, manila, mod, tf3d, touchflo

Guest Quick Reply (no urls or BBcode)
Message:
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes