MaoTai_GUIT: a Windows console automation tool with a license gate and a thin source tree

The artifact people run is a Windows executable, not a Python package

A point worth making early: the thing most people run is a Windows console executable, not an installable library. There is no packaging manifest in the tree and no PyPI entry, so pip install is not a route into this project. The README states the current form as a Windows console program at version V1.33, last updated 2026-07-28, and lists the supported environment as Windows 10 or 11, plus Python 3.11 if you choose to run from source. Chrome or Microsoft Edge are required for QR scanning and security verification on two of the three platforms.

The README is explicit that Linux has not completed real login and packaging verification for the current version and is not an officially supported environment for it. That is unusual candor for a project of this kind, and worth reading as the actual support boundary rather than as a footnote.

The language is Python and the license field says Apache-2.0. The repository carries 2123 stars, 324 forks, and 10 open issues, and the last push landed on 2026-09-15. There are no published releases, which means a version like V1.33 exists in the README changelog with no corresponding GitHub release artifact to download or diff against.

Three platforms, three different login paths, and one shared session trick

One detail will confuse an English reader immediately: the README writes platform names in censored form. A certain treasure stands for Taobao, and a certain east stands for JD. This is deliberate rather than corruption, and it appears in the feature table, the menu, and the changelog alike.

The feature table gives one row per platform and separates login from everything after it, which is the most useful single view of the project. Taobao handles login through a QR image, SMS verification, and an independent browser as fallback, then moves into product validation, appointment, and the rush itself, and this row is marked as connected. JD reuses a local cookie file first, validates that cookie online, and falls back to regenerating a QR code, then proceeds through the same validation, appointment and rush path, also marked connected. Damai, the ticketing platform, has QR image login, SMS verification and a browser fallback on the login side, but the table states that ticket grabbing is not performed at all: login is connected while ticketing is under development.

The cross-platform behavior is more interesting than the table implies. After a successful Taobao login the program goes on to obtain a valid JD session and then enters the existing JD appointment and rush flow, and the README states plainly that the Taobao cookie is never passed into JD interfaces. Damai login succeeds and then prints a real username plus a notice that the ticketing feature is in development, and the README states that it will not call JD interfaces and will not simulate Damai purchase results. That last sentence is a small but meaningful choice: the tool declines to fake a success it cannot produce.

Four config keys, two timeouts, and one opaque authorization check

The runtime configuration is unusually small, which is a good sign for anyone auditing what the program can reach. Four keys in `config.ini` matter: `exeUser_key` carries the authorization information the program checks at startup, `exeUser_sku` names the JD product SKU, `exeUser_user_killTime` optionally overrides the rush time using the format `YYYY-MM-DD HH:MM:SS:mmm`, and `exeUser_Cookie` exists only for compatibility with older versions because a successful login now writes to local cookie storage instead.

Login timeouts live in a separate file, `configWeb.ini`, one section per platform:

[taobao]
login_timeout = 180

[damai]
login_timeout = 180

A three minute timeout per platform, which is generous enough to cover a QR scan and a delayed SMS code.

The `exeUser_key` requirement is worth pausing on. An Apache-2.0 repository whose README requires per-user authorization, and whose menu flow begins by checking an announcement, version, maintenance status and that authorization, is running a license gate. The gate is the one part of the pipeline that cannot be audited from the repository, and it is the part that determines whether a given build will proceed at all.

Cookies are stored per platform and replaced atomically

Login state is kept per platform in three JSON files under a `cookies/` directory:

cookies/jd.json
cookies/taobao.json
cookies/damai.json

The README explains that these files are replaced as temporary files rather than written in place, specifically to reduce the risk of corruption if the program is interrupted, which is a small sign of care about the failure modes people actually hit. Cookies are checked for expiry and revalidated online, and if the server has invalidated them the program logs in again. The optional kill time is the other user-facing control, and it accepts millisecond precision, which tells you the intent is to fire against a scheduled second rather than a rough minute.

The privacy section is the most direct writing in the README. It asks readers not to publish cookies, SMS verification codes, card keys, device identifiers, or captured traffic in logs, issues, chat records or submissions. It also makes a point that is correct and often skipped: if a repository copy ever contained real credentials, deleting the file does not invalidate them, and the right response is to log out on the platform, change the password, or rotate the credential. Given that the subject here is session cookies for shopping accounts, that is advice worth taking seriously rather than skipping past.

Concurrency is defensive: shared success state and a single time correction

Concurrency in the rush path is built to stop rather than to hammer. Multiple rush threads share a success state, so once one thread succeeds the others stop submitting, and the V1.33 changelog records this as the fix for threads continuing to submit after a successful purchase. Server time drift for JD is corrected exactly once, and the same notes list repeated application of the time offset among the bugs fixed. They also describe a signature branch whose result was being overwritten, the removal of external requests at module import time, and the addition of request timeouts with TLS certificate verification enabled.

Read together, those five items are the clearest statement of intent in the repository. The project is trying to stop hammering a platform after it has already succeeded, to keep request signatures intact, to avoid network traffic as a side effect of importing code, and to fail closed on certificate validation. None of that changes whether the underlying activity is permitted by the platforms involved, but it does describe a codebase that has been debugged against real failures rather than sketched out in a weekend and abandoned.

A thin tree, a void tutorial, and license terms that go beyond Apache-2.0

The repository tree is thin. It contains `LICENSE`, `README.md`, a directory of JD area identifiers, an `imgs/` folder, a `peizhi.txt`, and an image file whose name states that the free software must not be sold. No Python modules, no test suite, and no packaging manifest appear in it. So the README describes a Python 3.11 source workflow while the tree exposes almost none of that source, and the documented route to the program is a prebuilt executable plus a set of hosted document tutorials. Those tutorials are linked as the new and old user guides, with the newer one marked as void, and separate documents cover how to tell whether a rush succeeded and how to capture traffic from Android and iPhone.

The Damai integration is the clearest unfinished surface. Login and cookie management work, and the README states that product search, session selection, ticket tier selection and order placement are all not yet wired up. The limitations section is equally honest, noting that the tool cannot guarantee a purchase because inventory, account state, network conditions and platform rules all still decide the outcome, and that platform interfaces and risk control pages can change at any time, which may force rework of the QR and SMS flows.

The licensing terms deserve their own note, because they do not match what Apache-2.0 usually means in practice. The disclaimer restricts use to personal study and non-commercial projects and includes a clause requiring downloaders to delete the code and its derivatives within 24 hours of stopping use. That is a restriction the Apache-2.0 grant does not normally impose, so anyone planning to build on this needs to resolve the disagreement between the disclaimer text and the LICENSE file first. The README also carries a long anti-fraud section naming accounts and unrelated repositories it associates with scammers selling this software, and a note that donations have stopped because they already covered development costs.

Editorial conclusion

Start by deciding whether you want to read this code at all, because the repository exposes configuration, storage layout and login flow in detail while exposing almost none of the implementation, and the authorization gate is opaque. What the documentation does settle is the shape of the system, the per-platform cookie hygiene, the shared-success-state fix, and the honest admission that Damai ticketing is unfinished. What it does not settle is what the license key authorizes or how the tool responds to the risk control it clearly runs into. Version V1.33 dated 2026-07-28 with a push on 2026-09-15 suggests work continues on those flows, and the linked tutorials are where a reader would look first.

Frequently asked questions

Official sources

1. chao325/MaoTai_GUIT on GitHub
2. Issues
3. License: Apache-2.0
4. README