GMV Checker (EDR for ATMs) Technical Analysis (Part 1) / TUTORIAL

[d0j0]

http://eternalcbrzpicytj4zyguygpmkj...1b9f2b14b99bbe81df/03e2cf584e03ed44de94b4.bmp

Hey there this is a series of tutorials based on the GMV Checker
structure, components, protocol, client/server architecture, potential attack vectors, encryption types, and disassembled/interpreted code by yours truly.

Note: This post will be the least dense of the entire GMV Checker series. If you have questions, suggestions, or corrections, feel free to drop them here. Everything here will be published FOR FREE for the community. If you spot plagiarism, hit me up via DM.

Let's start with the components:

http://eternalcbrzpicytj4zyguygpmkj...493e9196bbf642180b/bbac50f1f55c18c6e7e54a.png

- kernel drivers (XP specific and others for newer versions): protector.sys, kb_protector_xp.sys, kb_protector_nt.sys
- Service/daemon/client: Checker.exe
- keyboard protector installer: kb_protector_installer.exe
- ACLs (Access Control Lists): Applied to the acl folder


The communication protocol with the Java-based server (JBoss) is simple and rudimentary, which makes sense given ATM bandwidth limitations. A basic structure might look like this:

http://eternalcbrzpicytj4zyguygpmkj...ab42f7e4e6ee09448983/6a9b3c8916a1b7e8618a.png


This line suggests a policy tied to system processes. For example, the executable at \SystemRoot\System32\autochk.exe has an MD5 hash: 100307A13956BD15B99A57C6A763463B. The values after the hash are config/state parameters (process ID, privileges, trust states). Why do this? Simple: if Checker.exe detects a hash mismatch (via ACLs), it triggers a red flag, activating defense protections and logging activities.

Thanks to GMV's team, they've shared excellent documentation on their protocol, magic numbers, and client/driver code. Here's the link to their materials:


http://eternalcbrzpicytj4zyguygpmkj...6b06b8fb8db52161c049/16892e90e8ea94c507d8.PNG


http://eternalcbrzpicytj4zyguygpmkj...0b0cecd2348bf4cf7d73429e/fa36b5c8eee35a4f.PNG


http://eternalcbrzpicytj4zyguygpmkj...a77d305d1d19a70f2dd8c2/dde4072fc25c3b49ae.PNG


http://eternalcbrzpicytj4zyguygpmkj...738e2f848c0da362/8137c7977f984768c8653534.PNG


http://eternalcbrzpicytj4zyguygpmkj...df27104d5da071707d3686/25df73cda8840260b8.PNG

These images don't need extra explanation they're self-explanatory.

Let's dive into the code. Now, the fun part: IDA Pro
IDA Pro time.


http://eternalcbrzpicytj4zyguygpmkj...b53c7ea0e02364/0bcc91239048c8f835727a6860.png

At 0x140034728, we see a routine checking ACLs. The function TCPSChecker__recv_AUT_RSP is named here, located in the .rdata section of the PE file. This is a virtual function (since all .rdata functions crash with printf on failure). GMV devs saved us time by embedding function/class names directly huge thanks to them.



http://eternalcbrzpicytj4zyguygpmkj...c8b1424ca16e3f7a89ba68/0bd3a0873cd55a23f8.png


At 0x140075A9C, Checker.exe calls CryptAcquireContextW (Windows CryptoAPI) to create an RSA context. The XOR operations at 0x140075A92 and 0x140075A95 zero out registers r8d and edx, which in C would look like:

HCRYPTPROV hProv;
CryptAcquireContextW(&hProv, NULL, NULL, PROV_RSA_FULL, 0xF0000000);

The NULL parameters are the XOR-zeroed values.

http://eternalcbrzpicytj4zyguygpmkj...f9aff3494308c0bd8511/3d969624cea664f2e5fd.png

At 0x0140075AB1, CryptGenRandom generates 4
graphically secure bytes, which are then used in math operations (imul) on local buffers.

Alright, I think that's a solid intro. Don't want to overload you with low-level details just yet.

TL;DR:
Any support, criticism, or even a bit of friendly teasing is welcome.

Happy hacking!