How to extract source code from Native Client .nexe file, migrate to WebAssembly?

[guest271314]

This is probably not within the purvey of WebAssembly though you are th experts re compilation/decompilation of native code, and Google recommends migrating from Native Client to WebAssembly https://developer.chrome.com/docs/native-client/migration/.

Google released an extension which relies on Native Client that includes a voice that can be used with Web Speech API window.speechSynthsis.speak(). In that extension exists speech synthesis engine in the form of .nexe US English Female Text-to-speech (by Google.

What I want to do is extract the C++ source code from the .nexe file and migrate from the deprecated Native Client to WebAssembly.

How do I achieve that?

[guest271314]

I tried

$ llvm-objdump --arch-name=wasm64 -d tts_service_x86_64.nexe

which prints a series of

invalid_type, invalid_type ...

[sbc100]

nexe files contains x86 instructions, so you won't want to specify the wasm64 arch when using objdump on them.

There is no way to automatically convert x86 instructions (in the nexe) into WebAssembly instruction. The migration path from Native Client to WebAssembly involves to back to the source code and re-compiling, rather than binary file translation.

[guest271314]

I have not been able to locate the source code for nexe files.

All I have located is the nexe files in the extension and https://chromium-review.googlesource.com/c/chromiumos/platform/assets/+/1093522/.

[guest271314]

There is no way to automatically convert x86 instructions (in the nexe) into WebAssembly instruction.

According to Automatically convert x86 assembly to C there is a way to convert x86 assembly to C.

C to WebAssembly intruction appears possible Compiling a New C/C++ Module to WebAssembly so what am I missing in the flow chart that does not allow direct conversion from nexe to WebAssembly instruction?

I really want to read the C/C++ source code before attempting to convert to wasm, however the last time I ran objdump >> file the machine froze as the nexe is 25MB. Ideally I pipe the dumpt directly to a program that converts to C/C++, if that is possible, then test converting to WASM.

[sbc100]

Its not really feasible to take the automatic conversion path since that APIs used by WebAssembly and NaCl are also very different. Unless you are really determined and have a lot of resources I just don't think its a reasonable approach.

[guest271314]

The source code for tts_service_x86_64.nexe must be somewhere in Google source code.

Unless you are really determined and have a lot of resources

Yes, I am really determined. I have been working on this subject matter since at lest 2017 https://lists.w3.org/Archives/Public/public-speech-api/2017Jun/0000.html. That is why I wrote https://github.com/guest271314/SpeechSynthesisRecorder (which is how we ultimately get to the present issue, detailed below), https://github.com/guest271314/native-messaging-espeak-ng,https://github.com/guest271314/SSMLParser, and https://github.com/guest271314/captureSystemAudio.

The context for this issue is this answer https://stackoverflow.com/a/70665493 only captures silence. I contacted the author and advised him of the history of the topic re the specification and implementation issues I had filed. I linked to https://github.com/espeak-ng/espeak-ng/tree/master/chromium_extension, which is based on one of the links above. They replied that the voice was not up to par. They filed https://stackoverflow.com/questions/70694704/tts-software-used-in-chrome-for-speechsynthesis trying to locate source of PATTS. Based on deduction I concluded tts_service_x86_64.nexe must be assembly code of the in-house Chrome speech synthesis engine, designed to work with Google voices. Thus I began attempting to "reverse engineer" the code we have.

I just don't think its a reasonable approach.

I am open to reasonable approaches you suggest.

[sbc100]

This doesn't sounds like a issue that wabt can help you to solve. Reverse engineering x86/x64 binaries is not something wabt can help you with I'm afraid.

[guest271314]

$ hd tts_service_x86_64.nexe

and

$ strings tts_service_x86_64.nexe

provide some details https://gist.github.com/guest271314/4894662d31ffb4ad2cd57683721bf4b4. Still some work to do.