Hoho Hub script: Sources, Keys and Listing Status

What does the Hoho Hub script collection show?#

Hoho Hub groups listings whose titles or loader URLs match the hub name. Blox Fruits is the only game represented in our Hoho data. The collection contains 4 listings and 4 copyable entries across 1 game. A matching name or URL helps you find related uploads. It does not authenticate each upload as a developer release.

We fetch loaders as text and never run them, so a status is not proof a script works. The cards above show the copyable loaders. When reading a card, separate the person who uploaded the listing from the GitHub account hosting its target and the person maintaining Hoho. Our data identifies uploaders and source accounts, but no named individual behind the project.

The Blox Fruits script collection places these entries alongside other listings for the same game. Use the game collection to compare listings under the same game, then check each upload’s source and date. The four Hoho records below give you those details in one place.

Hoho listings, dates and key requirements#

The 26 October 2026 text-fetch snapshot recorded three entries as loader reachable and one as statically screened. Loader reachable means the target returned HTTP 200 but obfuscation or protection prevented inspection. Statically screened means readable fetched text had no red-flag patterns found by the static scan; the label does not describe a runtime result.

The DeathKing listing advertises auto-farm, auto-raid, kill-aura, teleport and auto-buy. The pull listing advertises auto-farm, auto-raid, ESP and teleport. Those attributes come from uploader titles or descriptions, not from executing the advertised functions. Our listing data contains no feature claims for the Vip and fruit fruit farm entries. Avoid filling those gaps with features advertised by another upload, even when both carry the Hoho name.

The oldest title explicitly mentions PC and mobile. That wording comes from the uploader; device compatibility remains unverified. Likewise, Vip does not establish a paid edition, and the less descriptive fruit fruit farm title does not establish a separate developer. The ScriptBlox discovery API provided listing metadata; hosting and ownership require a separate look upstream.

Who are acsu123 and ascn123?#

The observed Hoho loaders point to GitHub owners acsu123 and ascn123. Three listings point to acsu123 and one to ascn123. None of the four ScriptBlox uploader names matches either upstream owner, so the uploader names should not be presented as Hoho’s developers.

The acsu123 account was created on 3 June 2021. Our 26 October 2026 review found an empty profile bio and a HohoV2 repository pushed on 11 October 2026 with no licence recorded. A repository push date establishes activity in that repository; our review does not identify the changed files or connect that push to every older listing.

The ascn123 account was created on 26 January 2024. Our review found two public repositories, HOHO_H and HohoV2, with no licences recorded. The same review also found repository push timestamps of 24 January 2024, preceding the recorded account creation date. That ordering remains unresolved and cannot support a release chronology or ownership claim.

The relationship between acsu123 and ascn123 remains unverified. When comparing destinations, read the owner segment immediately after the GitHub host, then the repository name that follows it. HohoV2 under one account is a different destination from HohoV2 under the other. Keeping the full path makes that distinction visible when a repost shortens its source attribution to “GitHub.”

GitHub hosting and the Pastebin query#

All four Hoho entries use raw.githubusercontent.com as their loader host. The host identifies GitHub raw-file delivery; the owner, repository, branch and path identify the particular target. A familiar host by itself does not establish who authored the fetched content.

The search “Hoho Hub script Pastebin” does not match the hosting shown here: none of these Hoho loaders uses Pastebin as its listed host. Our wider Blox Fruits data includes Pastebin-hosted entries, but sharing a game does not make those entries Hoho releases. Check the actual destination before treating a search result as a match.

A repost should therefore be compared with the exact destination in its source record. Changing a title or moving a loader into another paste does not establish a new upstream release. Our Hoho review does not document every nested URL, so GitHub as the recorded loader host must not be expanded into a claim that every dependency is hosted there.

After checking the source destination, read the key requirement attached to that specific listing.

Is a Hoho Hub no-key claim supported?#

A blanket “Hoho Hub script no key” description is unsupported by this snapshot. Three entries have required key status, and the fourth has unknown status. The catalogue derives key requirements from uploader flags or detected key-system code; an unknown result must not be rewritten as a claim that no key is needed.

Key-system markers appeared in three fetched chains at the 26 October review. Obfuscation also appeared in three chains. Those are separate observations: a key marker concerns access-related evidence, while obfuscation concerns how much fetched code can be inspected. Read the key requirement and code readability as separate fields when comparing entries.

The statically screened DeathKing entry still has an unknown key requirement. A static scan looks for patterns in readable text. Our review did not document the complete current access process, so the absence of a detected marker leaves that question open. The mistake to avoid is treating the most inspectable listing as proof of a no-key edition.

The Roblox script key-system guide explains the distinction between an uploader claim and a detected marker. Any claim about present access should remain tied to its specific listing, which also matters when considering the age of these records.

What do the 2022–2024 listing dates mean today?#

The Hoho listing dates span 26 April 2022 to 25 February 2024; the editorial review date is 26 October 2026. An older listing can still point to a reachable target, but a successful text fetch does not establish compatibility with the current Blox Fruits experience.

Three dates answer different questions here: the listing date records when the discovery entry appeared, a repository push date records upstream repository activity, and the fetch date records the source observation. Substituting one date for another creates an unsupported freshness claim. The acsu123 HohoV2 push in October 2026 does not turn a 2022 upload into a newly verified gameplay release.

Our review did not establish a current Hoho release number, changelog, feature-by-feature compatibility result or runtime assessment. Labels such as Vip and the repository name HohoV2 should remain names used by the listings and repositories, rather than a reconstructed sequence of editions. For a freshness check, ask which date a claim refers to. A page updated in October can still describe an upload from 2022; those dates tell you different things.

The excluded Loading_UI record needs the same care with dates and source details.

Excluded records: unknown is different from dead#

The related excluded record is titled https://raw.githubusercontent.com/acsu123/HOHO_H/main/Loading_UI. Our data gives it unknown status, with no usable loader or HTTP result. The record’s title resembles a raw GitHub destination, but that title alone is insufficient to supply the missing fetch evidence.

The Hoho-specific exclusion list does not document a dead result. Under the site’s vocabulary, dead requires HTTP 404, HTTP 410 or an empty target; unknown means the target could not be fetched. Calling this excluded record dead would replace a missing observation with an HTTP result we never obtained.

The wider Blox Fruits exclusion ledger includes dead entries from other sources, but those do not establish a Hoho-specific failure. Exclusion can also depend on rights or source evidence, so inclusion and HTTP status answer different questions. If a Copy Code button is missing, read the stated category before deciding why. A missing button alone cannot tell you whether a source failed to respond or lacked the documentation needed for inclusion.

The catalogue methodology explains the text-fetch and listing policy behind these distinctions. A source review can then use those categories without executing a script.

How can you check a claimed genuine Hoho copy?#

A source comparison can help you spot mismatched owners, destinations and dates. No single title authenticates a Hoho-branded copy, so use the following checks together and leave missing details unresolved.

1. Read the listing attribution. Record the title, uploader and listing date. Keep the uploader separate from the upstream account. DeathKing and pull identify uploaders here; crediting either as the developer would go beyond what their listing records show.
2. Compare the full destination. Read the host, owner, repository and path against the source record. Check acsu123 and ascn123 character by character. A familiar GitHub host tells you where the file is delivered from; it does not explain the relationship between those two accounts.
3. Separate names from release evidence. Look for documentation that connects a version claim to a specific source. Leave the current release number unverified when that documentation is absent. HohoV2 is a repository name and Vip is a listing label; neither supplies a complete release history.
4. Read the dated status and key evidence together. Keep an unknown key requirement marked unknown, even on the readable entry. HTTP 200 describes a response from the target, while the key field describes what we could establish about access.
5. Keep unresolved evidence unresolved. Compare new claims with the missing details identified here. For the excluded Loading_UI entry, the missing loader and HTTP result still matter. Copying its URL-shaped title into a source field would hide that gap instead of resolving it.

The source-verification guide expands this documentation process. A comparison with Redz shows why the same process can produce different findings for different hubs.

Hoho Hub and Redz Hub source comparison#

Hoho and Redz have different documented source situations. Our Hoho review identifies multiple upstream owners and mostly protected fetched chains. Our Redz review documents a readable router in tlredz/Scripts and a specific empty game target at the review date.

The Redz Hub source and status page explains the empty Blox Fruits target and distinguishes the developer’s access claim from observed code. The empty file is a specific source finding you can weigh when comparing the records. Hoho’s protected chains leave more of the fetched code unreadable. Those differences support a comparison of source visibility, but provide no basis for ranking runtime performance.

The Redz Hub versus Hoho Hub comparison provides the broader side-by-side decision context. Account consequences remain a separate consideration regardless of the source comparison.

Roblox rules and the limits of this index#

Using third-party scripts or executors to exploit Roblox breaks the Roblox Terms of Use, and accounts can be banned. Roblox’s cheating and exploiting guidance also warns that exploit downloads can contain malware or phishing programs. We fetch loaders as text and never run them, so a status is not proof a script works or protects your account.

The Blox Fruits game description warns against exploiting and states that the developer does not appeal its bans. No device, executor or protected build was validated for this page. For players and parents researching an upload, the practical distinction is clear: source information can help explain what a listing points to, but it does not grant permission to exploit the game.

redzhub.dev is independent and is not the Redz Hub developers’ site. Use the Hoho Hub script collection to compare attributed listings, dated source checks and unresolved details. Before trusting a newer claim, look for a specific source and documentation that answers the missing question. The FAQ below covers paid-edition labels, device claims, Discord invites and reuse rights.