[gui] Hex view data error

[Asteri5m]

Issue details

When looking at the resource file, the hex view's data content is different from what I saw using the 010 Editor. When I use the algorithm in the program to decrypt, only the latter data is available

Jadx version

1.5.0

Java version

21.0.3

OS

• Windows
• Linux
• macOS

[jpstotz]

Ist it possible to provide the APK file that contains the shown libc.so? Or at least a screenshot of 7-Zip having the APK opened and showing the libc.so entry with size, compressed size and compression method.

[Asteri5m]

This is a virus, use with caution. Do not run on real machines. pass: jadx_sample asteri5m ***@***.***  

…

------------------ 原始邮件 ------------------ 发件人: "skylot/jadx" ***@***.***>; 发送时间: 2024年4月23日(星期二) 下午3:36 ***@***.***>; ***@***.******@***.***>; 主题: Re: [skylot/jadx] [gui] Hex view data error (Issue #2160) Ist it possible to provide the APK file that contains the shown libc.so? Or at least a screenshot of 7-Zip having the APK opened and showing the libc.so entry with size, compressed size and compression method. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

[jpstotz]

@Asteri5m Sorry I don't see any file. It seems like posting attachments via e-mail to Github issues is not possible.

[Asteri5m]

41514E30ADB73AC904296DFBF4C029A1.zip

[jpstotz]

The main problem is that the HexArea that display the hex data is getting the data to be displayed from a String that is then decoded as UTF-8 string to a byte[]:

jadx/jadx-gui/src/main/java/jadx/gui/ui/codearea/HexArea.java

Line 51 in b80f32a

byte[] bytes = binaryNode.getCodeInfo().getCodeStr().getBytes(StandardCharsets.UTF_8);

For binary files, the unicode decoding can modify the data which is most likely the reason you have described in this issue. Binary data should never be saved in a String...

I think for a JResource node with ZipRef it would be more feasible to directly load the raw file data from the ZIP file instead of using the loaded data from the node.

I made a quick test using the following code and it loads the correct hex data. @skylot Do you see any side effects when loading the hex data directly from the ZIP file?

	public void load() {
		byte[] bytes = null;
		if (binaryNode instanceof JResource) {
			JResource jResource = ((JResource) binaryNode);
			ResourceFile.ZipRef zipRef = jResource.getResFile().getZipRef();
			if (zipRef != null) {
				try (ZipFile zipFile = new ZipFile(zipRef.getZipFile())) {
					ZipEntry entry = zipFile.getEntry(zipRef.getEntryName());
					if (entry == null) {
						throw new RuntimeException("Zip entry not found: " + zipRef);
					}
					if (ZipSecurity.isValidZipEntry(entry)) {
						try (InputStream inputStream = ZipSecurity.getInputStreamForEntry(zipFile, entry)) {
							bytes = inputStream.readAllBytes();
						}
					}
				} catch (IOException e) {
					throw new RuntimeException(e);
				}
			}
		}
		if (bytes == null) {
			bytes = binaryNode.getCodeInfo().getCodeStr().getBytes(StandardCharsets.UTF_8);
		}
....

[skylot]

Binary data should never be saved in a String

I agree, this is should be avoided at all.

Do you see any side effects when loading the hex data directly from the ZIP file?

I think this is fine, but it is better to not duplicate such big chunk of code and reuse loading code from

jadx/jadx-core/src/main/java/jadx/api/ResourcesLoader.java

Line 56 in f5accc8

public static <T> T decodeStream(ResourceFile rf, ResourceDecoder<T> decoder) throws JadxException {

Another approach is to make loading similar to ImagePanel. It is store byte array in ResContainer with type DECODED_DATA

jadx/jadx-gui/src/main/java/jadx/gui/ui/panel/ImagePanel.java

Line 39 in 6e8affc

private BufferedImage loadImage(JResource res) {

and loading of data is done here:

jadx/jadx-core/src/main/java/jadx/api/ResourcesLoader.java

Lines 117 to 118 in f5accc8

	case IMG:
	return decodeImage(rf, inputStream);

Anyway, both ways are fine, because all resource code loading is a mess and should be simplified and refactored 🤣

[Asteri5m]

It seems that the problem has been resolved. I hope to update this bug and release a new release as soon as possible. This feature is still very practical. Like

[jpstotz]

From my perspective the direct way using ResourcesLoader.decodeStream would be the best as the other ways seem to base on ResourceLoader.loadContent which also considers the type of the resource which is not what we want for a hex view.

[jpstotz]

@Asteri5m You don't have to wait for a new version to be released. Once my PR is merged into the code base the Github CI system will build a new unstable version which you can then download here: unstable download (also mentioned in the main project README.md).

[skylot]

resource code loading is a mess and should be simplified and refactored 🤣

Looks like @AndreiKud already start refactoring in PR #2165 👀