l1nna / jvd Goto Github PK

Given the following setup

• jvd running under WSL
• IDA Pro installed on Windows
• symbolic links created somewhere on WSL path to link expected of IDA Pro Linux executables filenames to actual Windows executables

In jvd/disassembler.py, line 33 (disassemble function), a new temporary directory gets created alongside the file to disassemble, IDA Pro gets spawned as a disassembler and Linux paths automagically gets translated into \\wsl... path for Windows IDA process. All is fine until the path/filename in WSL is very long and exceeds MAX_PATH (260) characters. IDA Pro for Windows can't open path/file longer than that.

There is no easy script-in-the-middle workaround here to copy files around temporarily, as IDA Pro command line parameters (including Python script parameters) could also refer to other "long paths", including the "log file" IDA parameter. That script couldn't know whether paths in arguments refer to current or new files, or even files to append stuff to.

A suggested fix would be to use an OS-provided temporary folder (actually a unique temporary folder under it), instead of creating a folder at the binary file location. Using standard Python package functionality here also alleviates the need to manage the folder creation and deletion manually.

See Pull Request #12

Limitation: while the created temporary folder is typically on a short path, such as /tmp/tmp.random_id, this would still not prevent a failure on a very long file name under it. In practice, file names (name only, no path) with 240+ characters seldom occur. Overall, this would not affect Linux-only use cases, while being a best-effort fix for WSL + Windows IDA.

Current run-per-call design is flexible and robust, but with the JVM it is still very very slow.

• Further benchmark of performance
• Verify the need of a singleton Ghidra disassembly as service

Several design issues:
As a service, it is difficult to maintain, manage failures, and schedule resource provisions.