Make your video test requests!

:cautious:

I’m not complaining about the 403, you are stuck on a HTTP request in your answer

i didn't block anything, give me the zip DROP BOX file here if you beleive i am the only one who is blocked, the zip file you have downloaded from MY HUAWEI

give me the hash signature Too first,

do you know something about redirection about proxy crime redirection ?

for the last time as you can see i am not blocked by HUAWEI.CN i am blocked because there is a broken delivery chain

meaby shawdora is from asiatic continent ? that is why he was able to download it


Capture d'écran 2025-08-19 202837.png
Capture d'écran 2025-08-19 202717.png
 
:cautious:

I’m not complaining about the 403, you are stuck on a HTTP request in your answer

i didn't block anything, give me the zip DROP BOX file here if you beleive i am the only one who is blocked, the zip file you have downloaded from MY HUAWEI

give me the hash signature Too first,

do you know something about redirection about proxy crime redirection ?

for the last time as you can see i am not blocked by HUAWEI.CN i am blocked because there is a broken delivery chain

meaby shawdora is from asiatic continent ? that is why he was able to download it


View attachment 290285View attachment 290286
A broken delivery chain would typically result in a different type of error, such as a timeout, a 404 Not Found, or a server not being reachable at all.

<Code>AccessDenied</Code>

This is the most crucial part of the message. It is the server's definitive response, stating that the request was denied because the user lacks the necessary permissions to access the resource. This is not a network error, a broken link, or a missing file. The server knows the file exists but has been instructed to refuse access to the user.

The most likely cause for an AccessDenied error is a permissions problem. A regional block is a specific type of permissions problem, where the user's location is what's being checked for the access control policy.

Other possibilities include incorrect credentials, a bad user role, or a misconfigured bucket policy (for S3-compatible storage).

The AccessDenied error is a precise and explicit signal from the server. It means the server received and processed the request and then, for a specific reason defined in its configuration (which could be a regional block), denied it. It is not a generic network error.
 
:cautious:

I’m not complaining about the 403, you are stuck on a HTTP request in your answer

i didn't block anything, give me the zip DROP BOX file here if you beleive i am the only one who is blocked, the zip file you have downloaded from MY HUAWEI

give me the hash signature Too first,

do you know something about redirection about proxy crime redirection ?

for the last time as you can see i am not blocked by HUAWEI.CN i am blocked because there is a broken delivery chain

meaby shawdora is from asiatic continent ? that is why he was able to download it


View attachment 290285View attachment 290286
I'm located here in the US and don't get blocked by Huawei Cloud Security. And here the Dropbox link. Dropbox. I will take it down with week. I hope I not breaking forum rule for sharing a download link.

You got to be patient and talk politely when trying to prove appoint.
1755894272820.png
 
I'm located here in the US and don't get blocked by Huawei Cloud Security. And here the Dropbox link. Dropbox. I will take it down with week. I hope I not breaking forum rule for sharing a download link.

You got to be patient and talk politely when trying to prove appoint.
View attachment 290424
by the dropbox link : "Dropbox",

the version soft : EDR-Agent-Personal_1.1.25.719_windows_x64.exe
from your download from a computer to an other one, were made the 27-07-25 at 16:38
wich has a
  • Installer (EXE):
    B9258DBC865F951D1897793B03B96B5FC07147CF9CAFC17AA8CCAD4F69A2F58992865B911E8F7482B96987CD3DD382A02ADA57CF0FA143825C3F83AD9E6FB2C7 hash : sha512

  • &

  • ZIP package:
    563CA8878CB3A65FFF536AAE55A0A0533413FC9875D04916A66A081E818DBDC8C83AD7DEBA9FA5A1E6E84F3FCC01CDAF22B09793CE438EB974B8E345C084EAD8 hash : sha 512
do not match the official SHA-512 displayed by Huawei in the image you sent me

1755894272820.png


So, for authenticity, please download it again directly from the official Huawei support portal:


because access requires login via the official platform (and upgrading your profile if you didn't upgraded it):


Please provide a screenshot showing:
  1. That you can actually access the download page,
  2. The latest version number available, and
  3. The official SHA-512 hash published by Huawei.
If you truly have partner access, this should not be an issue.
But let’s be clear: authentic EDR builds are not publicly downloadable by everyone, which is why they cannot be legitimately found on Reddit or random file shares like dropbox—especially not the latest version.

here is the last recognition from a china reputable lab AV test
1653712a-4385-4763-ba9d-2bbe48c874e2.jpg


The June 2, 2025 build is Not tested yet

finally here is my point :

The last official version of Huawei HiSec Endpoint available for Windows users is still 1.1.25.505, dated April 10, 2025:
👉 https://support.huawei.cn/enterprise/en/doc/EDOC1100459738/426cffd9/about-this-document

As already mentioned, this software is not globally distributed and requires partner-level access:
👉 Get Pricing/Info - Huawei Enterprise
 
do not match the official SHA-512 displayed by Huawei in the image you sent me
Every time you download it there is a different hash. This actually is free. Also, it's been tested by AV-Test and rated as a top product. That's a pretty solid result for a fake antivirus :ROFLMAO:
 
No,

hashes don’t change on each download. That’s literally the point of a cryptographic hash: same file = same hash, always. If your build gives different hashes every time, it only proves the files are inconsistent and cannot be trusted.

Also, AV-Test results only apply to the official version Huawei submitted (1.1.25.505). They do not validate your Dropbox build.

If you really want to use AV-Test as an argument, then ask them directly which SHA-512 hash they tested. Because on the page you linked, this information is not provided — even though the test is official. 👉 Make a screenshot of their answer.

Please consider also these real-world examples of stolen or abused signing private keys:


 
It does in this case. If you open the page in two different browsers, the hash shown and the hash of the downloaded file will be different for each browser.
If the hash changes on every download, the file is unverifiable. That is the opposite of what you want from an enterprise-grade EDR product.
This is why only an official, static SHA-512 published by Huawei can prove authenticity. Anything else is just a security risk.


And yes, there is a timestamp in the file, but this one is not dynamic.
It comes from DigiCert Trusted G4 RSA4096 SHA256 TimeStamping CA, valid from September 2024 until November 2026.
Once applied, it never changes. So if the hash is different on every download, that’s not because of timestamping — it simply means the file itself is inconsistent or modified.


@roger_m
browsers don’t magically rewrite executables.
If the hash is different depending on which browser you use, that only means the server is delivering inconsistent files — which is even worse.
For a signed enterprise EDR, the hash must always be the same, regardless of the browser, the OS, or the network path.
Anything else = corrupted or tampered files


👉 Case closed for me until @minhgi provides the official SHA-512 hash from the Huawei repository.
 
browsers don’t magically rewrite executables.
If the hash is different depending on which browser you use, that only means the server is delivering inconsistent files — which is even worse.
For a signed enterprise EDR, the hash must always be the same, regardless of the browser, the OS, or the network path.
If you reread my post, you'll see that the hash shown on the website, which is something you posted a screenshot of, changes. So the hash of the downloaded file should match what is shown on the website at the time of downloading it.
 
If you reread my post, you'll see that the hash shown on the website, which is something you posted a screenshot of, changes. So the hash of the downloaded file should match what is shown on the website at the time of downloading it.
ps : i don't want to reply more, please let expert security auditor do there job, and know i ignore you.
 
Last edited by a moderator:
A lot of AVs patch the executable (after the last bytes) with unique identifiers, which could include anything, from license key to telemetry binding information, that allows monitoring of installation quality and so on.
This is why the hash is different on every download.
That’s done in the overlay section of the executable, which is just being read by the rest, not executed. That’s why digital signatures are not invalidated. When Windows calculates the hash, it won’t take the file from start to finish.

In addition, the package may be compiled in real time by including the latest signatures and components (typical for endpoint protection products)
 
Last edited:
Instead of focusing on a changing hash, you should always verify the digital signature of any executable you download.

How to Check a Digital Signature on Windows.

Right-click the executable file.

Select Properties.

Click the Digital Signatures tab.

Select the signature from the list and click Details.

Check that the "Digital Signature Information" says, "This digital signature is OK."

By confirming this, you can be 100% confident that the file you received is the exact file the company intended for you to have, despite any unique data appended to the end. Relying on this established, cryptographically sound method is a much more secure and reliable practice than trying to match a public hash that could be easily compromised.
 
@Trident

I’m certain you know many things, but I’m also sure you know nothing about security as part of Windows hardening.
no matter if you collaborate with some AV manufacture.

Here is why:

An EDR executable with a valid signature and timestamp cannot be patched in place.
Any modification (even 1 byte) would break the signature (and would immediately fail any official computer audit ordered by a judge).

That’s why every new build is always distributed as a new installer (with its own SHA-512 and release notes), not as a “tiny patch”.

👉 You don’t patch an enterprise-grade EDR like a video game.
You uninstall the old build and install the updated one.

Every serious EDR works this way (Defender ATP, CrowdStrike, SentinelOne, Huawei HiSec…).

For example:

Microsoft Defender for Endpoint update for EDR Sensor - Microsoft Support

“NOTE: this update gets released periodically, and with the same KB number (5005292). When it is deployed, this article will be updated with the latest version number for MsSense.exe. It may take a while before the package is fully available for all channels including WSUS — this may mean that the version reflected in the Windows Update Catalog remains behind until broad deployment is reached.”

So if you claim otherwise, then show me, beyond whatever you’re “building” on your side — a single enterprise EDR that patches its signed executable in-place.

For this topic, the real name of EDR-Agent-Personal_1.1.25.719_windows_x64.exe is HiSec Endpoint.exe — and nothing else.

And no, I’m not talking about a home antivirus.

👉 Expected answer: You won’t find one.
 
Last edited by a moderator:
  • HaHa
Reactions: roger_m
@Trident

I’m certain you know many things, but I’m also sure you know nothing about security as part of Windows hardening.
no matter if you collaborate with some AV manufacture.

Here is why:

An EDR executable with a valid signature and timestamp cannot be patched in place.
Any modification (even 1 byte) would break the signature (and would immediately fail any official computer audit ordered by a judge).

That’s why every new build is always distributed as a new installer (with its own SHA-512 and release notes), not as a “tiny patch”.

👉 You don’t patch an enterprise-grade EDR like a video game.
You uninstall the old build and install the updated one.

Every serious EDR works this way (Defender ATP, CrowdStrike, SentinelOne, Huawei HiSec…).

For example:

Microsoft Defender for Endpoint update for EDR Sensor - Microsoft Support



So if you claim otherwise, then show me, beyond whatever you’re “building” on your side — a single enterprise EDR that patches its signed executable in-place.

For this topic, the real name of EDR-Agent-Personal_1.1.25.719_windows_x64.exe is HiSec Endpoint.exe — and nothing else.

And no, I’m not talking about a home antivirus.

👉 Expected answer: You won’t find one.
You've brought up a critical point about the integrity of signed executables, and it's a topic that's often misunderstood. Your claim that a digitally signed EDR executable cannot be patched in place is absolutely correct in principle. Any modification to the signed code sections of an executable will indeed break the digital signature, making the file invalid.

However, the premise that this is why every new EDR build requires a full uninstall and reinstall is an oversimplification of how modern security software operates. As @Trident correctly pointed out, there are specific, legitimate technical methods that allow for updates without invalidating the digital signature of the core executable.

The key lies in the PE (Portable Executable) file format used by Windows. A program's code, data, and resources are stored in specific sections that the Windows loader maps into memory. The digital signature protects the integrity of these critical sections.

There is, however, an optional section called an overlay. This is a block of data appended to the very end of the executable. This data is not part of the signed sections and is not mapped into memory by the Windows loader. The program itself can open its own file and read this data, but because it's outside the signed sections, you can modify it without invalidating the digital signature.

This is a well-established practice used by many software vendors, including those in the security industry, to append unique, per-installation data like, telemetry binding information to link the agent to a specific customer or account,unique installation IDs for quality control and diagnostics, license keys or other configuration details.

This is why two downloads of the exact same version of an EDR installer can have a different SHA-512 hash, even though the core executable and its digital signature are identical and valid. The hash is different because of the unique data in the overlay.

So, while you are correct that the signed executable's code is immutable, many EDR vendors use a combination of techniques, including overlays and pushing smaller, signed update packages for individual components, to update their products without requiring a full reinstall. This makes the update process much more efficient and practical, especially in large enterprise environments.
 
Last edited by a moderator:
@Divergent

This will be my last polite answer before I let @Shadowra continue with their video request (and I’ll just provide more screenshots for those still trying to discredit me).

I will not reply back to @Trident for security purposes.

Listen,

Here is something important you should consider

👉 Mitigations - Enterprise | MITRE ATT&CK®

(MITRE ATT&CK – the world authority behind CVEs and security standards)
“Mitigations represent security concepts and classes of technologies that can be used to prevent a technique or sub-technique from being successfully executed.”
M1045: Code Signing
According to MITRE ATT&CK mitigation M1045 (Code Signing), executables must be verifiable through their digital signatures.


In practice this means a static, reproducible hash published by the vendor.
If the SHA-512 changes on every download, integrity cannot be verified. That defeats the entire purpose of code signing and is a red flag for enterprise security.


What “in practice” means in the world of trusted digital communication:

  1. Microsoft (Authenticode)

“Authenticode® time stamping is a digital signature format that is used to determine the origin and integrity of software binaries.”
(Source: MSRC)


Authenticode is based on:
  • PKCS #7 SignedData (publisher info, URL, and timestamp)
  • X.509 certificates. (2.)

2. IETF RFC 3161 (Time-Stamp Protocol, §2.4.1)

“The messageImprint field SHOULD contain the hash of the datum to be time-stamped.”
(RFC 3161)

This means that when a vendor timestamps a signed executable, what is being certified is the exact hash of that binary at that moment.


In other words:
The timestamp protects the integrity of the signed hash over time.
👉 If your SHA-512 changes on every download, you’re not verifying the same signed object — and you break the entire mechanism of long-term trust.
 
Last edited by a moderator:
  • HaHa
Reactions: roger_m
Some posts were edited for reason: disparaging remarks against each other.

For everyone involved in this discussion, no need for bickering who is right or not, what should be always correct is the social behavior of all forum people.

Now it's time for agree to disagree, otherwise this thread might be locked temporary!
 
Instead of focusing on a changing hash, you should always verify the digital signature of any executable you download. [snip]
no offfense intended but... I was dealing with a hash issue y/day and I happened to ask ChatGPT 5 about it, and its reply was basically verbatim what you wrote above (not that there's anything wrong with that...) :unsure: