# Report IP - reproduces double-clicking the "Report IP" desktop icon.
#
# Seeded from source control by plugins/endpoints/api/reportipscript.py. Edits
# made to the library row are overwritten on the next seed: the corptools
# allowance grants this script BY NAME, so the name has to keep meaning this
# reviewed body.
#
# RUNS IN THE USER SESSION, and that is a hard requirement rather than a
# preference. Measured on a live endpoint, launching this tool as SYSTEM has it
# immediately re-enter the interactive session - the work ended up in a separate
# process under the signed-in account (session 1) while the SYSTEM-side launcher
# exited 0 within a second, having observed nothing. Every attempt to capture
# output or a verdict from the SYSTEM side therefore reported success for work
# it never saw.
#
# This is the same session-0 boundary EndpointCollector documents for mapped
# drives: a SYSTEM process has no view of a user's drive table, HKCU or profile.
# The agent's user-context path crosses it properly (CreateProcessAsUser into
# the active console session) and returns the child's real exit code, so the
# verdict below is trustworthy in a way the SYSTEM path could not be.
#
# Consequently this script stays deliberately thin: the agent owns launching,
# waiting and output capture. Re-implementing any of that here is what produced
# the false results.

$ErrorActionPreference = 'Stop'

# Resolved from the shortcut when present, so the arguments stay whatever the
# icon on the desktop actually uses. The fallback matches the installed tool.
$ShortcutPath = 'C:\Users\Public\Desktop\Report IP.lnk'
$Exe = 'C:\ProgramData\ReportIP\GE_ReportIP_3_v1.EXE'
$ExeArgs = @('/ForceUpdate=True', '/S')

# Working directory comes from the vendor's own scheduled task definition
# (\ReportIP), which runs the tool from its install folder.
$WorkDir = 'C:\ProgramData\ReportIP'

if (Test-Path -LiteralPath $ShortcutPath) {
	try {
		$link = (New-Object -ComObject WScript.Shell).CreateShortcut($ShortcutPath)
		if ($link.TargetPath) {
			$Exe = $link.TargetPath
			if ($link.Arguments) { $ExeArgs = @($link.Arguments) }
			if ($link.WorkingDirectory) { $WorkDir = $link.WorkingDirectory }
		}
	} catch {
		Write-Output "could not read the shortcut, using the installed path: $($_.Exception.Message)"
	}
}

if (-not (Test-Path -LiteralPath $Exe)) {
	Write-Output "executable not found: $Exe"
	exit 2
}

if (-not (Test-Path -LiteralPath $WorkDir)) { $WorkDir = Split-Path -Parent $Exe }

# Identity is logged because it is the thing most likely to be wrong: if this
# ever reports SYSTEM, the run is meaningless for the reasons in the header.
Write-Output "running as: $([Security.Principal.WindowsIdentity]::GetCurrent().Name)"
Write-Output "session: $((Get-Process -Id $PID).SessionId)"
Write-Output "launching: $Exe $($ExeArgs -join ' ')"

# -Wait, and the tool's own exit code is the verdict. No success-string scan:
# the tool reports its outcome through its own channel, and inferring success
# from console text was what produced both false failures and false successes
# in earlier revisions.
$process = Start-Process -FilePath $Exe `
	-ArgumentList $ExeArgs `
	-WorkingDirectory $WorkDir `
	-PassThru -Wait

Write-Output "exit code: $($process.ExitCode)"
exit $process.ExitCode