OpenSSL/BoringSSL version detection

[x1mus]

Hi,
I was playing a bit with ecapture and figured out that whenever we are on android. The library would always be detected as BoringSSL even if the preceding detection returns the correct OpenSSL version.

Android natively provides BoringSSL (if I'm not mistaking) but apps could ship OpenSSL directly within their build process. Therefore providing an openssl library with --libssl=openssl-path.so on android will prevent the decryption from working if we do not provide a specific libssl version because we overwrite this value afterwards.

Detection is performed here:

ecapture/user/module/probe_openssl.go

Line 204 in ff16186

err, verString := m.detectOpenssl(soPath)

Then if we are on android, we overwrite the detected value by our own (ie: "boringssl_a_<android_ver>"):

ecapture/user/module/probe_openssl.go

Line 252 in ff16186

if isAndroid {

Here's the modification I did on my side to patch the detection in my case. However, I did not do so much further testing so this might not be a good solution:

var bpfFileKey, bpfFile string
	isAndroid := m.conf.(*config.OpensslConfig).IsAndroid
	androidVer := m.conf.(*config.OpensslConfig).AndroidVer
	if verString != "" {
		m.conf.(*config.OpensslConfig).SslVersion = verString
		m.logger.Info().Str("origin versionKey", verString).Str("versionKeyLower", verString).Send()
		// find the sslVersion bpfFile from sslVersionBpfMap
		var found bool
		bpfFileKey = verString
+		bpfFile, found = m.sslVersionBpfMap[bpfFileKey]
-		if isAndroid {
+		if isAndroid && !found {
			// sometimes,boringssl version always was "boringssl 1.1.1" on android. but offsets are different.
			// see kern/boringssl_a_13_kern.c and kern/boringssl_a_14_kern.c
			// Perhaps we can utilize the Android Version to choose a specific version of boringssl.
			// use the corresponding bpfFile
			bpfFileKey = fmt.Sprintf("boringssl_a_%s", androidVer)
+			bpfFile, found = m.sslVersionBpfMap[bpfFileKey]
		}
-		bpfFile, found = m.sslVersionBpfMap[bpfFileKey]
		if found {
			m.sslBpfFile = bpfFile
			m.logger.Info().Bool("Android", isAndroid).Str("library version", bpfFileKey).Msg("OpenSSL/BoringSSL version found")
			return nil
		} else {
			m.logger.Warn().Str("version", bpfFileKey).Err(ErrProbeOpensslVerBytecodeNotFound).Msg("Please send an issue to https://github.com/gojue/ecapture/issues")
		}
	}

[dosubot[bot]]

Hey, @x1mus! I'm here to help you with any bugs, questions, or contributions you have. Let's dive into this issue and work on resolving it together.

To improve the detection of OpenSSL/BoringSSL versions on Android in the ecapture code, your modification is on the right track. Here are some key points to consider:

1. Conditional Check for Android: Your change ensures that the BPF file is only overwritten with the Android-specific version if the initial detection fails (!found). This prevents unnecessary overwriting when the correct OpenSSL version is already detected.

2. Fallback Mechanism: By checking if the BPF file is found before applying the Android-specific logic, you maintain a fallback mechanism that uses the detected OpenSSL version when available.

3. Logging: Your modification includes logging the original version key and the Android-specific version key, which is helpful for debugging and understanding which version is being used.

4. Testing: Since you mentioned limited testing, it would be beneficial to test this modification across different Android versions and configurations to ensure it handles various scenarios correctly.

Overall, your approach helps in maintaining the correct version detection logic by using the Android version as a fallback only when necessary. This should improve the accuracy of the BPF file selection process on Android devices.

To continue talking to Dosu, mention @dosu.

---

^{Help Dosu learn! Give it feedback: Great Response | Irrelevant Answer | Incorrect Sources | Too Verbose | Hallucination | Bug Report | Other}

[cfc4n]

In the Android operating system, the BoringSSL class library is used by default, so by default (that is, no --libssl parameter is specified), it will be set according to the offset address of the BoringSSL class library.

If you are an Android expert, you will probably use the --libssl parameter.

So, I think this is a suitable solution.

Or, do you have any better ideas?

[x1mus]

Wouldn't this mean that issuing --libssl makes the usage of --ssl_version mandatory on Android system ? Since not specifying the later could result in a misidentified ssl version. Or having a warning that this could be misidentified in the output of the tool.

[cfc4n]

The biggest problem is that in the BoringSSL source code, the version symbols are the same string and will not be updated. Therefore, it is impossible to distinguish the version by this character, and can only be distinguished using the corresponding default version on Android.

see https://github.com/gojue/ecapture/blob/master/utils/boringssl_android_offset.sh for more detail.