CydandClaude Opus 4.8
b9d8027cf6
Make the Console<->Launcher system source-built and modern now that the console is under our control and the WinXP-era pods are gone. Contract extraction (Contract/Tesla.Contract.csproj): - One multi-targeted (net48;net8.0-windows) source project for the RPC contract, replacing the vendored TeslaConsoleLaunchLib.dll and the hand-synced Tesla.Net replica in Launcher/LaunchModels_Shared.cs. Emits assembly TeslaConsoleLaunchLib. SecureConfig extraction (SecureConfig/Tesla.SecureConfig.csproj): - net48 source of the first-boot provisioning protocol (UDP beacons, OFB crypto, RSA key exchange), replacing the vendored TeslaSecureConfiguration.dll. Remove BinaryFormatter from the wire (RCE sink + the reason net6 was pinned): - Console<->Launcher RPC is now length-prefixed System.Text.Json frames (Contract/PodRpcProtocol.cs) over the unchanged OFB transport; dispatch by method name. Deleted the SerializationBinder / MethodInfoProxy machinery. - Console-local BinaryFormatter (Site config, mission replays) intentionally retained: local net48 file I/O, not the network surface. Runtime modernization: - Launcher Service + Agent: net6 -> net8, win-x86 -> win-x64 (all pods are 64-bit Win10). Kept the SHA1-default PBKDF2 (Console key-derivation compat) with SYSLIB0041 suppressed and documented. Tests: differential suite now 73 green. Added SecureConfigCompatTests (OFB ciphertext byte-identical to the vendored DLL) and PodRpcProtocolTests (JSON round-trip of every request/response shape); removed the now-obsolete BinaryFormatter byte-identity guard. Build hygiene: per-project obj dirs (Launcher/Directory.Build.props) fix a NuGet restore collision between the two Launcher projects sharing one folder. NOT runtime-verified against a live pod. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
TeslaConsole.DiffTests — differential equivalence suite
Verifies that the reconstructed TeslaConsole.exe (built from the decompiled
source in this repo) behaves identically to the original reference binary in
original/TeslaConsole.exe.
How it works
Both files carry the exact same assembly identity
(TeslaConsole, Version=4.11.3.37076), so the .NET loader will not hold both in
one AppDomain. The suite therefore loads each assembly into its own child
AppDomain (DifferentialFixture) and drives it through a MarshalByRefObject
proxy (Invoker). This is why the project targets net48 — AppDomains are a
.NET Framework feature.
Each child domain is given a probe directory (the recovered build's output, which ships every dependency DLL) so the original — which is distributed without its proprietary dependencies — still resolves its references for metadata inspection.
What is compared
-
Public API surface (
PublicApiSurfaceTests) Every public type and public member (signature-for-signature) exposed by the original must also be exposed by the recovered build. Compiler-generated members and property/event accessor methods are excluded — the README at the repo root notes those legitimately differ between a decompilation and the lost sources. -
Behavioral output (
BehavioralEquivalenceTests) The same deterministic, dependency-free methods are invoked in both assemblies over a battery of inputs and the results must match byte-for-byte:RPStrings.GetTimeString(mm:ss formatting + 0.5 s rounding)HostTypeHelper.Parse(...).ToString()(incl. invalid-input exceptions)PlasmaBitmaps.ConvertBitmap(1-bpp packing of a known pixel pattern)PlasmaBitmaps.GenerateString(full GDI text → 1-bpp plasma pipeline)RPMap/RPVehicleXML parsingSiteManagementwell-known application GUID constantsTuple.Create<,>generic factory
A negative-control test (
Harness_Distinguishes_Different_Outputs) proves the harness can actually see a difference, so a green run is never vacuous.
Running
dotnet test tests/TeslaConsole.DiffTests/TeslaConsole.DiffTests.csproj
A project reference builds the reconstruction first, and the suite always tests
the most recently built bin/{Debug,Release}/net48/TeslaConsole.exe.
Scope / limitations
This compares deterministic logic. It deliberately does not drive the WinForms UI, the pod networking, secure-configuration, or hardware-facing code — those require the live console, its pods, and the proprietary services, and are not reproducible in a unit test. The API-surface test still asserts those types exist with matching signatures even though their behavior isn't exercised.