Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[AzuredreamsXT]

Does this file, part of DF Hack i believe, have any importance to Dwarf Fortress itself? AVG removed it, but seeing as i never use DF Hack or any of the other extra programs it provides, as long as it has no impact effect or use on the main game in any form i am content to leave it in the AVG virus vault.

Is this fine?

[peskyninja]

There are no viruses in DFhack.

[Bdthemag]

A few anti-viruses like AVG get a bit over zealous towards some programs, DF Hack itself has no viruses in it at all. AVG is just pretty stupid like that.

[Newbunkle]

He wants to know if he should bother rescuing the file since he doesn't use dfhack.

My theory is no, although I've never used it myself. I don't think it'll interfere with dwarf fortress itself if you leave it in the bin.

[Quietust]

If you don't know what it's for, then you don't need it - that particular tool is only useful for the sort of people who are working on DFHack itself.

[C0NNULL]

As was stated, if you do not use it you really don't know it is gone. *grin*

AVG and others remove it because, well let's face it, DFhack is a hack. (It tells you so. I've not played much with it, but anything that is trying to read into or write into another program...) As such, things on your computer that want to not let hack things on will likely find some of those things offensive. If you like, you can restore them of course. If you were someone that wandered up to me and asked I'd tell you to leave it alone. Since in effect that is what you've done, I respond exactly the same.  [Once, Norton once decided that AutoCAD 14 was offensive - since no one seems to use it, it wasn't in their database of trusted programs. *shrug* That was a different case, though.]

And absolutely nothing from the LNP or DFhack or anything else but DF is needed to run DF. You could delete LNP/C-Hacks/DFhack <version> and the rainbows tomorrow would be the same, TMBG would not need to re-write a song. I promise. (Caveat - If you are using graphics packs and remove them...)


Since I think I tldr'd it:
tldr - Your fine.

[G-Flex]

My question is: Why exactly is it possible for an external program (in this case, dfhack) to read and write to the memory space of another program (in this case, DF) in the first place? Doesn't Windows disallow that sort of thing?

[MadocComadrin]

It disallows writing to instructions memory I'm pretty sure, but I don't think it ever disallowed reading, especially if you're using C or C++, where you can grab memory that's not yours without thinking.

[G-Flex]

But with dfhack (and DF utilities in general), it's pretty obvious you can also write to the program's memory, or else you wouldn't be able to actually do anything.

[peterix]

My question is: Why exactly is it possible for an external program (in this case, dfhack) to read and write to the memory space of another program (in this case, DF) in the first place? Doesn't Windows disallow that sort of thing?

For admin users, the default is that any program can debug any other program. As long as you run them with the same set of privileges, you can read and write everything. And all the silly protections amount to nothing, because you can just ask the OS nicely and it will comply with the requests. So, if you want any protection at all, make sure you *always run things as normal user* and don't download shady crapware from the internet

A sane OS should never break this functionality. It's essential for any kind of software development. It might make sense to limit it to a set of whitelisted programs though. Compare this with for example Ubuntu, where this functionality is broken by a global on/off switch. There's no way to disable it without disabling protection for all programs that runs under the OS. This is VERY BAD, because it breaks every single debugger.

Good thing is, you don't need any of this anymore, because the new DFHack avoids the issue entirely by extending DF instead of hacking into it from outside.

[Starver]

MS haven't helped things by going 'straight from' the unsecured method to the UAC system, in which you tend to say "Yeah, I meant that" every time.  Every time.  You're checking the properties of the clock and click on the "change time" link (because, you know, having that functionality directly on the Date & Time window, with a handy cancel button and the close icon if you didn't mean it, was just so 'broken', that they had to separate it, right?) and UAC asks you to confirm that the Change Time window/program can be run...

Anyway, people tend to get so used to that that they always confirm it without reading it.  Which puts you back at square one as if it were as it were originally.

Not saying it's a totally bad thing, but it causes problems.  (Especially when you're doing a Windows Update, or something else official, and the UAC window actually hides behind the "35% done" installation window, and you didn't realise that for the last half hour it was awaiting your response on something that you'd have expected the semi-automated Windows Update process to have allowed to happen, seeing as you set the process off yourself.)

Haven't used Windows 7 enough to know if it's as bad.  It seems to be either improved or at least made so much less visible, for the few dozens of hours of total use of it that I've actually had.

*nix installations tend to (noted exceptions aside, and of course habitually running as 'root', to be a lot better because they've been built that way from the ground up.  And, it has to be said, used by more technical users who have a small inkling of how just the utilities they want to, and know[2] are safe can be given a sudo-type access, and most times even then not to 'root' but to something like the sqluser or webadmin pseudo-accounts or so...


Back to AVG, it'd be a heuristic match.  Instructions along the lines of checking for a certain running executable and poking it is a feature common to a number of malwares.  While most pre-existing malwares are now known by an actual signature of some kind (and can be named, even behind some metamorphic attempt to disguise, although the metamorphism is also commonly picked up, heuristically, in new stuff), this will pick up "gen/trojan-hijack.1234" or whatever name AVG gives this kind of thing.  IIRC you can whitelist processes in AVG, which you could do if you were going to use it (like I had to in order to make an officially-sanctioned JohnTheRipper run, on a machine whose AV (correctly!) pointed out that it was a bit of a naughty program).  And again, as others have said, if you're not going to use it then ignore its absence.

If you have a legitimate program, or are unsure but think that you're getting a false-positive, getting your AV vendor to have a look at the item being highlighted usually brings about either a personal or an added-to-all-updates 'exception' rule, once they confirm to their own satisfaction that it's a real and legitimate program.  I remember once the company I was in had a new licence update for SAS (Statistical Analysis Software, and the crux of their business) where the licence-code somehow (somewhere down the line, in the extensive licence-protection system integrated with their product) managed to provoke Sophos's scanners (though only the Netware .NLM version, IIRC).  We quickly got them to double-check the situation and provide an 'anti-signature' exception .IDE (their mini-update files) which resolved the situation (until the next major monthly update came about with a more permanently included exception, just like it included more permanent protections in place of the  mini-updates that had already occured).  Not sure if your use of AVG is via the free version or the fully paid-for one (which might affect exactly how quickly they want to support you on this) but if you had wanted to use it, I'm sure they'd do something similar for you.

But you don't.  I'm really just spelling it out in case someone else does need to sort something out in order to use that.  But, if I read it correctly, DFHack now works differently and doesn't trigger the same.


[2] YMMV.

[peterix]

MS haven't helped things by going 'straight from' the unsecured method to the UAC system, in which you tend to say "Yeah, I meant that" every time.  Every time.  You're checking the properties of the clock and click on the "change time" link (because, you know, having that functionality directly on the Date & Time window, with a handy cancel button and the close icon if you didn't mean it, was just so 'broken', that they had to separate it, right?) and UAC asks you to confirm that the Change Time window/program can be run...

Setting time is a privileged operation. You have to have root rights on linux to do that. The same dialog on linux systems will ask you for password (policykit ftw). Hell, setting time can break apps that don't expect that to happen. IMHO, this is perfectly understandable and actually done right. It just needs to ask for an actual admin to login

Anyway, people tend to get so used to that that they always confirm it without reading it.  Which puts you back at square one as if it were as it were originally.

Yep. Security theatre. If the OS just asks you if you meant to do what you're doing, then it's the equivalent of not asking at all. Requiring admin login verifies that the user that initiated the action does have the rights to do it. Nobody can walk up to my linux machine and set its clock. Or mess with the running system services. Or install anything. That is actual security.

Back to AVG, it'd be a heuristic match.  Instructions along the lines of checking for a certain running executable and poking it is a feature common to a number of malwares.  While most pre-existing malwares are now known by an actual signature of some kind (and can be named, even behind some metamorphic attempt to disguise, although the metamorphism is also commonly picked up, heuristically, in new stuff), this will pick up "gen/trojan-hijack.1234" or whatever name AVG gives this kind of thing.  IIRC you can whitelist processes in AVG, which you could do if you were going to use it (like I had to in order to make an officially-sanctioned JohnTheRipper run, on a machine whose AV (correctly!) pointed out that it was a bit of a naughty program).  And again, as others have said, if you're not going to use it then ignore its absence.

My point is this: the OS itself should have a whitelist of allowed debuggers. You want to add your debugger? Sign it, add the certificate. That would be sane. In practice, this sort of issue is a big free-for-all. Look at Ubuntu and their silly kludge that breaks more than it fixes. Unsigned debuggers wouldn't get access to the required API calls. This alone would break a good portion of malware, or at least some of their functions, while providing a sanctioned way to actually do this kind of stuff without triggering crappy AV protections. In the current state, there's no standard way to make a weird app work properly :/

If you have a legitimate program, or are unsure but think that you're getting a false-positive, getting your AV vendor to have a look at the item being highlighted usually brings about either a personal or an added-to-all-updates 'exception' rule, once they confirm to their own satisfaction that it's a real and legitimate program. 

I reported the problem to AVG and they ignored me completely. I'm actually thinking about visiting them... Their offices are ~20km from here

But, if I read it correctly, DFHack now works differently and doesn't trigger the same.

Yes. I'm replacing the SDL lib with my own stuff. For DF, it's still the same old SDL. For me, it provides a way to sync with DF's execution properly (no more race condition bugs!) and do all kinds of awesome things with no hacks. DFHack is written in C++ and is compiled as any other normal, boring library now No debugging crap, no problems with protections (it's the same process, many of the OS calls that would fail when used from different processes just work), no assembly anywhere.

Thanks to the LGPL license used for SDL, this is not only possible, but legally protected. The user has to be able to replace SDL.

[Lac]

DF Hack itself has no viruses in it at all.

There are no viruses in DFhack.

I think you guys are missing the point of viruses; or you meant trojans.

[peterix]

DF Hack itself has no viruses in it at all.

There are no viruses in DFhack.

I think you guys are missing the point of viruses; or you meant trojans.

What?

[Twiggie]

I think you guys are missing the point of viruses; or you meant trojans.

i was going to say this, but with worms instead of trojans. hey ho