Fix DexParser method initialization

[wangwillian0]

These bugs make the DexParser to not fill all the methods correctly, introducing unwanted nulls.

[JingMatrix]

Please provide examplar apps to show that you are solving some issue.
Currently, I don't see that your code is correct.

[Dev4Mod]

So far I’ve seen only a few projects that use the Modern API and also use DexParser directly for obfuscated code, but judging by the fix it’s making, it seems to be correct — after all, there really are initialization issues. To test it, the only way is by creating a POC.

One app I know that uses the Modern API is PlayStrong, but it has a problem with this LSPosed that causes issues with the service bridge. I haven’t investigated the issue deeply though. PlayStrong is closed-source and only works with the official LSPosed (a private version called IT).

[JingMatrix]

Nobody needs a closed source PlayStrong. My open-source project TEESimulator can help getting STRONG integrity.

From this block, I don't see why would @wangwillian0 remove / 3 operation in the for loop.

LSPosed/core/src/main/java/org/lsposed/lspd/impl/utils/LSPosedDexParser.java

Lines 78 to 81 in e9cb36b

	this.methodIds = new MethodId[methodIds.length / 3];
	for (int i = 0; i < this.methodIds.length / 3; ++i) {
	this.methodIds[i] = new LSPosedMethodId(i, methodIds[3 * i], methodIds[3 * i + 1], methodIds[3 * i + 2]);
	}

It is surely introducing a bug.

[Dev4Mod]

Alright, first: I mentioned PlayStrong only as an example of an app that uses the Modern API — I wasn’t saying it should be used. Sorry if it somehow sounded offensive toward open-source code.

Second, in this.methodIds = new MethodId[methodIds.length / 3]; we’re already dividing by 3 on that line, and then inside the loop we divide again with this.methodIds.length / 3. The confusion comes from the "this" — look closely at it. I was confused at first too.

[JingMatrix]

No worry, I wasn't being offended. My tone was a bit aggressive, sorry for causing the mis-understanding.

Oh, you were right, I missed the this part as well.
Thanks for the clarification. I will inspect this problem with more details.

[wangwillian0]

Hi @JingMatrix. It's basically what @Dev4Mod said.

The second bug is more pronounced, you can see that this.parameters[0] and this.parameters[1] are simply never iterated through at all.

[JingMatrix]

@wangwillian0 Thanks for reporting this bug. Given the low quality of the original Java class, I decide to refactor it into Kotlin.

Your fix for array length is correct, but the protoId is not correct. See my pull-request #509 for details.

[wangwillian0]

Your fix for array length is correct, but the protoId is not correct. See my pull-request #509 for details.

The logic of the Kotlin code looks the same as this PR, so I don't think this code was wrong, but nice to have the Kotlin rewrite. Thanks for handling the issue!

[JingMatrix]

The logic of the Kotlin code looks the same as this PR

Ah, yeah, you were right, I overlooked it. Sorry for that.