LUNA: A new step into the unknown of scripts

**lunapark** · 7th June 2021, 09:57 PM

In order to minimize the space occupied , the attached archives (post #3) only contain the decrypted lua files originally contained in the data.zip and the correspondings ux. The complete archives are available in various places of the forum or available when installing the apk in the corresponding obb files.

This is not the Grail, but it should allow seasoned skinners to continue further development and enrich their skins.

To each his own opinion, there are many similarities between all these versions but each contains very specific variations that cannot be mixed with the others.

Exclamation

Unicode values in wide strings to respect the source code are supported with hex values using the format Hex L"\xYYYY" or Decimal L"\YYY" (0 to 255) and should not not be modified at the risk of causing data loss or causing erratic behavior of the program

Spoiler: Part of keyboard.lua

Updated attachments are now available in post # 3, #15, and #19 to #23
[Only registered and activated users can see links. ]
v9.35.2.153810
v9.35.2.250945
v9.35.2.252289
v9.35.2.252374

[Only registered and activated users can see links. ]
v9.35.2.209092 (ZENEC)
v9.35.2.222726
v9.35.2.225936
v9.35.2.227616 (AVICSYNC-Pioneer)
v9.35.2.250929

[Only registered and activated users can see links. ]
v9.35.2.262743

[Only registered and activated users can see links. ]
v9.35.2.263562 (ISRAEL)
v9.35.2.263558(GIFT)

[Only registered and activated users can see links. ]
v9.35.2.250257 (for IOS)

[Only registered and activated users can see links. ]
v9.35.2.271066 (Vietnam)

[Only registered and activated users can see links. ]
v9.35.2.272868 & v9.35.2.272870

[Only registered and activated users can see links. ]
v9.35.2.274910 (Vietnam)

**ecotje** · 3rd July 2021, 08:22 PM

Very cool

, thank you. That makes a huge difference for modding!

I noticed there are a few errors, not sure if they are related to the disassembly.
For example, when I replace the original ux hg_search.zip with the disassembled version, there are errors in the program, whereas the original worked fine.

A specific example: in hg_search_base.lua, on several locations the line in function OneBoxSearch:SetupQuery(filter):

Code:

Please Login or Register to see the links

should read:

Code:

Please Login or Register to see the links

In fact, all the errors I found are related to wrong or missing function arguments, everything else is absolutely perfect.

Any ideas why this could be wrong? Totally not urgent, since I found/fixed the ones from the code I was modifying.

Version used: ux_9.35.2.153810 (corresponding to the same Luna version, running on an arm64 v8a phone)

**lunapark** · 4th July 2021, 01:35 AM

You are right the right format is the second, this is a bug caused by the decryption algorithm that Djeman used to create the Jigolua software and which does not take into account an additional specificity related to the decoding of LUNA .

we actually have two parameters that appear using it:

self.SetupSearchCenter [self.selectedCenterType] (self.SetupSearchCenter, self)

by analyzing this sequence given by jigolua

function OneBoxSearch: SetupQuery (filter)
self.query = sc_copy_table (self.defaultQuery)
self.query.filter = filter or ui.keyboard: InputValue ()
self.query.limit = self.maxResult
self.SetupSearchCenter [self.selectedCenterType] (self.SetupSearchCenter, self)
self.query.poi.providerIds = self: GetQueryProviders ()
self.query.poi.containerIds = self.selectedPoiContainers
self.query.poi.nameOnly = self.poiIsNameOnly
end

we immediately notice that 'self' must in fact represent the 'OneBoxSearch' entity

for my part, on the two parameters listed, I kept only the first one whereas it was the one he was going to eliminate

Spoiler: Click to see content

the content of the following code should be suitable to replace that of the lua

Spoiler: hg_search_base.lua

Thank you for reporting this bug, I think I identified its origin, I must check that it does not affect other lua files in the pack, otherwise in which case I will repost the corrections for all the archives as attachments to the first message

the list of impacted files is still quite small:

listseparator.lua, hg_search_base.lua, shop.lua, shop_enums.lua vr_ovde_parser.lua and speedcam.lua

A complementary attached list is available in post # 15
[Only registered and activated users can see links. ]

**ecotje** · 4th July 2021, 09:03 AM

Amazing find and already posted a new fixed archive!

It took a bit longer for me to pinpoint this exact issue because while looking for root-causes for things-not-working, I also hit "real" defects in the code.
Currently looking at some strange trigger() behavior but I will analyze the differences first between the "old" and "new" disassembled files, maybe the cause is there.

Please let me know if there is anything I can do to help or test. Don't know much about iGO but a decent programmer.

BTW, Is there also way to compile back the changed LUA? I know it needs a compiler with Wide String support and additional opcodes, made clear by the not-to-miss warning in the decompiled file.

**ecotje** · 4th July 2021, 12:29 PM

One more issue...
Could you take a look at i_hg_search.luad (the sections in bold) ?

Code:

Please Login or Register to see the links

There is a return statement missing and the return statement that is there belongs to the if statement.
The corrected (working) code is

Code:

Please Login or Register to see the links

Thanks in advance

**lunapark** · 4th July 2021, 01:54 PM

it is useless to recompile the lua for LUNA except for those who think that their modifications will be inaccessible, which is totally illusory, because in the current state of recompilations, it is without counting the programming errors as well as the generated coding by LUNA integrates a part of the unknown which no longer corresponds to the Primo style scripts,

the lua 5.1 standard is no longer fully respected with LUNA (it was not already respected before with primo and the widestring), and for that it would be necessary only to methodically disassemble the apk to extract the conversion mechanisms that can allow to reproduce the original scripts.

the main thing is that clear scripts can work fully with the correct syntax.
Whether they are in clear or not, iGO converts scripts into executable code on load to save execution time.

**ecotje** · 5th July 2021, 02:32 PM

I found a couple more issues in data_9.35.2.153810, specifically in address.luad. Replacing this module results in a hang.

Line 97: this code does not seem to correspond with the original

Code:

Please Login or Register to see the links

When I try to disassemble by hand it should be something like:

Code:

Please Login or Register to see the links

Also the line

Code:

Please Login or Register to see the links

crashes the code (does this function have an argument ?), so I changed it temporarily to

Code:

Please Login or Register to see the links

With these line in place, I can search countries but not cities, so I assume there are some more undetected errors.

**lunapark** · 6th July 2021, 04:24 PM

the result of the decryption I provided is quite correct and similar to what jigolua offers

get_country_and_state_text is a function which theoretically returns an L"" string
MODEL.address.search.get_country_and_state_text[CALL](string,wstring OUT) - input=string ; output=widestring

in programming 1 or 0 are also equivalent to true or false
we can just as well consider that a null string can be assimilated to false and true otherwise, so the form of the assignment string to boolean does not surprise me, on the other hand in clear text the interpretation can be distorted , all you have to do is correct the expression to perform a transcription

MODEL.lua.AddressSearchStreetsInState = MODEL.address.search.support_streetsearch_in_state(EAddressSearch.Result.selectedCountry) is found in different locations: address.luad , vr_ovde.luad , vr_ovde_search.luad ; et MODEL.lua.AddressSearchStreetsInState is only used inside asc.luad as

if not MODEL.lua.AddressCityIsSelected() and not MODEL.lua.AddressSearchStreetsInState() then

perhaps to solve it would be enough to write
MODEL.lua.AddressSearchStreetsInState = MODEL.address.search.support_streetsearch_in_state(EAddressSearch.Result.selectedCountry) and true or false

if so, it should influence many other similar forms elsewhere

in general when an instruction line is incorrectly formed, the downstream lines of code are ignored or cause the program to crash.
having made a test of this form

MODEL.SET.lua.test = BOOL_MODEL(true)
do
MODEL.lua.test = false
MODEL.lua.test = L"LUA"
sc_InfoMessageBox(tostring(MODEL.lua.test()),1)
end

the dialog box is displayed with the value false and the execution of the line MODEL.lua.test = L"LUA" is ignored

MODEL.lua.AddressSearchStreetsInState = MODEL.address.search.support_streetsearch_in_state(EAddressSearch.Result.selectedCountry) should therefore not require modification

------------------------------------------------------------------------------------------------------------

function sc_ShowSearchAddress(mode) does not exist in this form in the 153810 but has evolved in the following versions. on the other hand I have not found a location in the ui with a button or in the lua of a call to this function
it may therefore be that the apk could have been modified before compilation to use a parameter (mode) while the function in the lua was not updated

it must be taken into account that the scripts in 9.35.2.xxxxxxx show marked differences between them, the teams which develop them are not always the same, it is necessary to look in the corresponding ui to find the info like owners: gkaracsonyi experts: dflajsz

you have to be careful when trying to transcribe elements from one version to another as skinners who take functions from nextgen must do to transpose them into luna, it works but there are limits, that's why I looked at the sources to be as close as possible to the good names of variables and functions.

what can pose a problem is a bad interpretation in the decoding, but from there to miss the complete structure of a function, it is not technically possible, unless you have the wrong source file in the meantime

**ecotje** · 6th July 2021, 09:45 PM

Thanks for the quick reply and your efforts to look into my questions.

1. function sc_ShowSearchAddress()
You are 100% correct, the code is correctly decompiled. I have figured out where the problem is: the defect is elsewhere but it caused sc_ShowSearchAddress to fail.
Sorry for not finding it earlier and comparing with later versions this module.

2. MODEL.lua.AddressSearchStreetsInState = MODEL.address.search.support_streetsearch_in_state(EAddressSearch.Result.selectedCountry)
I agree with you that it's not a decompilation issue. I concluded this too rapidly because I tested just one single change from the original deployed APK version (with same version): replace compiled address.lua with the decompiled one in data.zip. But in the meantime, I have seen 2 instances where the correctly disassembled file fails due to defects in the code itself. It seems that when compiled, the defect does not show or it shows elsewhere.

You are right that this function appears multiple times but it also "crashed" at every single invocation. I should have been more clear that this line does not generate a true application crash. It is as you say: the function is aborted, the "print" statement I added at the beginning of the function is shown, but not the one right after this particular line. The result however is that the app does not function correctly. I will add the extra tests you suggested. Maybe there is some corruption, since there is one other MODEL.address.search function that crashes as well (City search). The EAddressSearch.Result.selectedCountry parameter is verified to be correct.

3. The other question in post #5
The modified code works, so only if you have time to spare. Here I found the "problem" by comparing with an an older (nextgen) version that JiGoLUA 2.2.2 decompiled.
This was the only difference that seemed not related to code changes, and when changed to the nextgen version, resulted in correct execution, hence my suspicion...

I have now validated and modified over 20 (large and complex) files and have become very convinced that the disassembly you posted is very robust and don't expect to find any more potential disassembly issues. Unfortunately, correctly disassembled does not always imply "working as per the original".

**lunapark** · 6th July 2021, 10:37 PM

It is not possible to know how the scripts of the luna are compiled, they can as well generated from a converter like JigoLUA or directly converted by the application which compiles the apk, I know one thing is that jigolua decompiles the lua in a way that recompiling may deviate slightly from the original file. the decryption obtained by a third party software may seem correct but the interpretation by iGO may not work, the binary interpreter and the text interpreter integrated in iGO may not be 100% compatible with each other.

as one can imagine attributing a string to a boolean can become functional with an implicit transcryption at the binary level but which must be specified when using a clear text

The main goal is to get as close as possible to a functional clear code while taking into account what iGO wants to digest, it always starts by adding control points slipped into the scripts to understand its reactions to certain syntaxes, which is not always obvious because sometimes we go to a haircut of the solution.

Edit:
After a return in different versions, it turns out that the function described as falling under a widestring is in fact a boolean, we find the same line in the address.lua of Primo where it is less complicated to display a simple dialogue
sc_InfoMessageBox(type(MODEL.address.search.support_streetsearch_in_state(AddressSearchResult.selectedCountry)),1)
returns a boolean type as expected, so no modification needs to be made at this level