Windows / PyInstaller — Package .s3d (Same Device Behavior) + Deliver Wrapper Source
Budget: $150 – $350 USD
On Windows, our KSuite-style desktop app normally reads Device.s3d from the same folder as the EXE. We want a distribution where end users cannot easily access/copy Device.s3d (best practical protection), while end-to-end behavior remains identical to the current working install (especially device visibility in the UI).
Hard acceptance criteria:
- After packaging/embedding, device detection and behavior must match the current working install exactly.
- Partial/wrong integration is not acceptable: if Device.s3d integration is not fully correct, the app may not detect the device or may error.
- Final validation will be performed by the client on real hardware (full remote device validation is not possible).
Expected technical approach:
- Typically a PyInstaller-built wrapper/launcher with correct working directory/runtime layout.
- If the engine requires a real filesystem path at runtime, the practical goal may be “no easy-to-copy Device.s3d sitting in the install folder” while still satisfying the engine’s requirements; clarify with a short PoC first.
Out of scope (strict):
- No invasive reverse engineering or binary patching of the third-party vendor engine (vendor EXE/DLLs).
Filename / installer compatibility (critical):
- The shipped main executable name MUST remain Ksuite.exe (name must not change).
- If a wrapper is required: the wrapper must be Ksuite.exe; the vendor engine EXE may be packaged under a different internal filename and launched by the wrapper.
- The installer/setup package will be produced by the client, so deliverables must fit that packaging flow.
Required deliverables:
- Full source code for the wrapper/launcher (Python or agreed stack)
- PyInstaller .spec + requirements + short README (re-pack steps)
- CI files if used (e.g., GitHub Actions)
- Note: vendor binaries (engine/DLLs) remain vendor IP; required source is the packaging/wrapper layer only.
Activation / keygen split:
- HWID activation + admin key generator will be handled by the client using existing in-house sources.
- The freelancer should NOT charge extra for implementing licensing; they must provide a clear hook point in the wrapper source to run activation checks BEFORE launching the vendor engine.
- CRITICAL: Do not deliver only a closed single EXE. Wrapper/launcher source must be delivered. Otherwise activation integration may require RE/patching and is out of scope.
File sharing:
- The full install/setup is too large for Upwork attachments. The attached .txt contains a download link for the full software/setup package (current version). Older embedded setup copies may be outdated—use the link.
- If needed, a ZIP of the current working install folder may be shared via download link (due to Upwork limits).
Working style:
- Prefer starting with a small paid fixed-price Milestone 1 (PoC): confirm path/CWD/native resolution and deliver a first working prototype.
- Avoid significant analysis/build work before the milestone is officially started on the platform.
Notes:
- Client performs hardware validation; if needed, a limited test activation scenario can be discussed separately.
Hard acceptance criteria:
- After packaging/embedding, device detection and behavior must match the current working install exactly.
- Partial/wrong integration is not acceptable: if Device.s3d integration is not fully correct, the app may not detect the device or may error.
- Final validation will be performed by the client on real hardware (full remote device validation is not possible).
Expected technical approach:
- Typically a PyInstaller-built wrapper/launcher with correct working directory/runtime layout.
- If the engine requires a real filesystem path at runtime, the practical goal may be “no easy-to-copy Device.s3d sitting in the install folder” while still satisfying the engine’s requirements; clarify with a short PoC first.
Out of scope (strict):
- No invasive reverse engineering or binary patching of the third-party vendor engine (vendor EXE/DLLs).
Filename / installer compatibility (critical):
- The shipped main executable name MUST remain Ksuite.exe (name must not change).
- If a wrapper is required: the wrapper must be Ksuite.exe; the vendor engine EXE may be packaged under a different internal filename and launched by the wrapper.
- The installer/setup package will be produced by the client, so deliverables must fit that packaging flow.
Required deliverables:
- Full source code for the wrapper/launcher (Python or agreed stack)
- PyInstaller .spec + requirements + short README (re-pack steps)
- CI files if used (e.g., GitHub Actions)
- Note: vendor binaries (engine/DLLs) remain vendor IP; required source is the packaging/wrapper layer only.
Activation / keygen split:
- HWID activation + admin key generator will be handled by the client using existing in-house sources.
- The freelancer should NOT charge extra for implementing licensing; they must provide a clear hook point in the wrapper source to run activation checks BEFORE launching the vendor engine.
- CRITICAL: Do not deliver only a closed single EXE. Wrapper/launcher source must be delivered. Otherwise activation integration may require RE/patching and is out of scope.
File sharing:
- The full install/setup is too large for Upwork attachments. The attached .txt contains a download link for the full software/setup package (current version). Older embedded setup copies may be outdated—use the link.
- If needed, a ZIP of the current working install folder may be shared via download link (due to Upwork limits).
Working style:
- Prefer starting with a small paid fixed-price Milestone 1 (PoC): confirm path/CWD/native resolution and deliver a first working prototype.
- Avoid significant analysis/build work before the milestone is officially started on the platform.
Notes:
- Client performs hardware validation; if needed, a limited test activation scenario can be discussed separately.