ExileAPI 3.12 Release

[Tonkan]

where can i get the addon that shows the xp u gain for each zone etc

GitHub - IlliumIv/MiscInformation

[its]

Hi, windows defender non-stop killed loader.exe
I added an executable to the exception, but still
Virus total:
VirusTotal

[Forumuser1000]

Hi, windows defender non-stop killed loader.exe
I added an executable to the exception, but still
Virus total:
VirusTotal

Same for me. It started happening about 6 hours ago. Windows defender just keeps targeting it.

[Queuete]

Hi, windows defender non-stop killed loader.exe
I added an executable to the exception, but still
Virus total:
VirusTotal

Same for me. It started happening about 6 hours ago. Windows defender just keeps targeting it.

Troubleshooting

1. The Hud wont start.
...
- turn of your firewall and antivirus and try again. (Thanks @bobTheBuilder69)

The last update was 2 days ago with a one line change from snowhawk within a context which makes no difference at all for antivirus detection. The last update before that was 15 days ago. So most likely your windows defender got updated and is trying to kill it now.

[VeryTraveller]

Infected! . Issue #63 . Queuete/ExileApi . GitHub Read this ASAP. @Queuete closed my "issue" on github. He said "AV got update 2 days ago"
Maybe his pc is infected and maybe he is didnt even know this but Last release %100 INFECTED!!! and "Win32/Wacatac.C!ml" is very dangerous ! Scan your pc and change your passwords ASAP

[Sychotix]

Infected! . Issue #63 . Queuete/ExileApi . GitHub Read this ASAP. @Queuete closed my "issue" on github. He said "AV got update 2 days ago"
Maybe his pc is infected and maybe he is didnt even know this but Last release %100 INFECTED!!! and "Win32/Wacatac.C!ml" is very dangerous ! Scan your pc and change your passwords ASAP

If you do not trust the binary he provides, you can rebuild the executable yourself and use that. I am not saying it is clean, but I have no reason to believe that the binary has been infected.

[VeryTraveller]

If you do not trust the binary he provides, you can rebuild the executable yourself and use that. I am not saying it is clean, but I have no reason to believe that the binary has been infected.

Believe me or not. Last version is INFECTED. As I said maybe he didnt even know. His pc is also infected. he needs to scan. If you need prof scan older versions. you will see what I mean

[pushedx]

Believe me or not. Last version is INFECTED. As I said maybe he didnt even know. His pc is also infected. he needs to scan. If you need prof scan older versions. you will see what I mean

Here's your basic misunderstanding about how AV scans work. I just did this myself because I've seen people make this mistake over and over.

The first scan you referenced was "cached" and was before AVs got updated. Upon scanning the file, the file was "clean" because at the time of the first scan, no AVs detected anything.

Some days passed and AVs got updated.

If you "rescan" the same file from before, it will now show it has issues, despite being the same exact file that was "clean" days ago.

This is because AVs got updated, despite the program itself not changing.

This can mean two things:
1. It's commonly a false positive
2. There was something undetected that is now detected and you should check your system

Here's the proof: Imgur: The magic of the Internet

Notice the file hashes are the same (since I just downloaded it from GitHub). Also notice in the clean scan, it was cached from 10 days ago. I triggered a new scan on the same file and it now has results showing up.

So it's pretty much what Sychotix and Queuete mentioned. Compile the program yourself if you don't trust it, but there's little reason to think it's magically infected now when it hasn't changed, but certain AVs did change.

[killergate]

Here's your basic misunderstanding about how AV scans work. I just did this myself because I've seen people make this mistake over and over.

The first scan you referenced was "cached" and was before AVs got updated. Upon scanning the file, the file was "clean" because at the time of the first scan, no AVs detected anything.

Some days passed and AVs got updated.

If you "rescan" the same file from before, it will now show it has issues, despite being the same exact file that was "clean" days ago.

This is because AVs got updated, despite the program itself not changing.

This can mean two things:
1. It's commonly a false positive
2. There was something undetected that is now detected and you should check your system

Here's the proof: Imgur: The magic of the Internet

Notice the file hashes are the same (since I just downloaded it from GitHub). Also notice in the clean scan, it was cached from 10 days ago. I triggered a new scan on the same file and it now has results showing up.

So it's pretty much what Sychotix and Queuete mentioned. Compile the program yourself if you don't trust it, but there's little reason to think it's magically infected now when it hasn't changed, but certain AVs did change.

Sure - but the updated AV-definitions of Windows Defender doesnt detect the .38 release at all - just the new .39 release...

/kg

[dlr5668]

Sure - but the updated AV-definitions of Windows Defender doesnt detect the .38 release at all - just the new .39 release...

/kg

Its very common to get false detection in net exe. For example, I had 31/70 in my app. After I split it to exe that loads dll it get reduced to 0/70. Same code just different load format

TLDR dont worrry

[GameHelper]

Its very common to get false detection in net exe. For example, I had 31/70 in my app. After I split it to exe that loads dll it get reduced to 0/70. Same code just different load format
TLDR dont worrry

I think it's very important (for the safety of the community) to understand the root-causes of these false/true detection and try to either identify them or resolve them. Last time it happened I step up (as an HUD developer and the person who builds the executable) to identify them and resolve them. I expect the same from current maintainers/developers of HUD. I had to format my whole computer, at that time, just to keep the community safer.


Also, community, please build your own Exe/Binary rather than depending on the maintainer/Developers binary till this issue is resolved. People work on HUD in their free time, so don't expect this to resolve soon.




On a separate note FYI: Announcements - New Stash Tab Folders and Affinities System - Forum - Path of Exile
No need for stashie anymore!!! yeay!!!

[pushedx]

I think it's very important (for the safety of the community) to understand the root-causes of these false/true detection and try to either identify them or resolve them.

Here's everything anyone should need to understand this is just another instance of a .net false positive.

Once again, I'm not saying the program is "safe", since I didn't write it myself, so I'm not going to vouch for any code I didn't write, but rather there's no evidence of any relevant changes to "loader.exe" to make me believe it's now actually infected with anything.

First, use a hex comparison tool (I use Hex Workshop) to see the differences between the old and and new file: Imgur: The magic of the Internet

As you can see, there's two sets of changes between .38 and .39.

The first one in the PE header is due to a recompile. It's only 3 bytes changed. Just knowing the basics of the PE header, you know that's not what's getting flagged (unless it was the only change, in which case you've certainly gotten unlucky with a sig match). Recompiles means date time stamp changed, so that's what this most likely is, but we can confirm it later.

The process to test is simple: modify each set of changes bytes and see if the exe is still flagged. If it is, you know that's not the sig being hit, and if it's not, you know it is. I've done this myself, and this first set of changes is not it, and I'd not expect it to be either for previously mentioned reasons.

Next set of changes is 16 bytes. I modified these bytes to all FF .. FF and reopened the file. No more AV flag, so this is the sig that got matched.

The question then is "what are these bytes for and why did they change"

Since "loader.exe" is a .net app, you can use "ildasm.exe" that comes with Visual Studio, and dump the exe along with the actual bytes of what is what. You can then compare the generated IL files to see what changed.

Here are the results: Imgur: The magic of the Internet

As you can see the first set is the compile time change.

The second set, which is what is causing the new detection, is because the MVID (Module.ModuleVersionId Property (System.Reflection) | Microsoft Docs) changed due to a recompile.

That's it. A uniquely identifying GUID (that has no relation to any executable code) changed due to a recompile and now AVs are flagging the exe as malicious.

This is simply a false positive, which happens with .net. The community solution is to just recompile a new exe and reupload it after making sure the new version doesn't get matched the same way (I had to open the loader in x64dbg to get my windows defender to trigger, scanning the file didn't do it).

Hope that helps!

[Sychotix]

Here's everything anyone should need to understand this is just another instance of a .net false positive.

Once again, I'm not saying the program is "safe", since I didn't write it myself, so I'm not going to vouch for any code I didn't write, but rather there's no evidence of any relevant changes to "loader.exe" to make me believe it's now actually infected with anything.

First, use a hex comparison tool (I use Hex Workshop) to see the differences between the old and and new file: Imgur: The magic of the Internet

As you can see, there's two sets of changes between .38 and .39.

The first one in the PE header is due to a recompile. It's only 3 bytes changed. Just knowing the basics of the PE header, you know that's not what's getting flagged (unless it was the only change, in which case you've certainly gotten unlucky with a sig match). Recompiles means date time stamp changed, so that's what this most likely is, but we can confirm it later.

The process to test is simple: modify each set of changes bytes and see if the exe is still flagged. If it is, you know that's not the sig being hit, and if it's not, you know it is. I've done this myself, and this first set of changes is not it, and I'd not expect it to be either for previously mentioned reasons.

Next set of changes is 16 bytes. I modified these bytes to all FF .. FF and reopened the file. No more AV flag, so this is the sig that got matched.

The question then is "what are these bytes for and why did they change"

Since "loader.exe" is a .net app, you can use "ildasm.exe" that comes with Visual Studio, and dump the exe along with the actual bytes of what is what. You can then compare the generated IL files to see what changed.

Here are the results: Imgur: The magic of the Internet

As you can see the first set is the compile time change.

The second set, which is what is causing the new detection, is because the MVID (Module.ModuleVersionId Property (System.Reflection) | Microsoft Docs) changed due to a recompile.

That's it. A uniquely identifying GUID (that has no relation to any executable code) changed due to a recompile and now AVs are flagging the exe as malicious.

This is simply a false positive, which happens with .net. The community solution is to just recompile a new exe and reupload it after making sure the new version doesn't get matched the same way (I had to open the loader in x64dbg to get my windows defender to trigger, scanning the file didn't do it).

Hope that helps!

Thank you for your continued contributions to the forum! This is a great explanation for going JUST far enough with digging into the binary.

[glbGG]

Hi! I am trying to write a script which uses map device. Got two questions here.

1. Are there any shared Enum Indexes for map device and map device buttons?
I'v already found those by myself with DevTree. Those are
IngameState.IngameUI.Children[60] for general map device window and
... [3][0][0] for 'activate' button.
But are those indexes stored somwhere in shared Enums?

2. I also want to check if the 'activate' button in mapdevice menu is clickable. (I.e. if it is highlited when i put a map inside and all options are set (zana mods) and map can be launched).
Is there any way to check this?

Thank you in advice!

[infoibrahimkekec]

Hello, I have some questions.
1- Is this bot mapping good with "Toxic Rain"
2- Can you help me for setup
3- Is there any video about how to use