question about memory footprint

[The Mad Poet]

How is the footprint defined?

If I were to create random arrays of random numbers and random data structures (in size) then would my footprint change?

personally I wouldn't find it hard to start some random allocs and such of random size that keeps the size of the program in memory changing from time to time - it would be quite easy to put some odds of changing the memory around also at odd times to keep the memory footprint changing.

Then to just write some variables out to with the program add some fluff data that is written on program close to the actual program file and possibly change the value of some (non used) constants that changes the actual file signature every time the program is closed - this would cause the program to:

A) change the CRC and size of the .exe every time it is run.

B) change the memory footprint and crc of the program in memory every time it is run.

Unless my ideas of the memory footprint are way off - you'll have to forgive me I never really considered the footprint of the program before and how to modify it - I've always been more focused on just making sure the damn thing ran...

[RavenCT]

Nice Sig!

[Ratt]

Footprint = The amount of space a program uses. Typically referred to in the context of memory. As in Memory Footprint.

Fingerprint = Tell-tale signatures that are unique to a single program, much like a real finger print.

Multiple programs can have the same memory footprint, but each will have a unique finger print.

The finger print is what needs to be obfuscated, not the foot print.

[The Mad Poet]

So in the end we really have to have a program that is able to change it's fingerprint every time it runs....

If there were a largish number of declared variables in the program - and those variable were directly altered in the .exe file by the .exe file before it closes - this would change the fingerprint the program created when it was run correct?

I'm not sure how else to do this - other than searching the seedier side of the web for some source to a polymorphic virus (which is essentialy what we would have to do - make the program change every time so that there was no 'standard' to search for).

The end game will be to make it require so many system resources to try and find the code in memory that any scanning attempt that they do would be more work/effort than they can afford.

On a side note -

It would be more than easy to call windows temp file routines to generate random file names for the keyfile - the question then would be could we set EQW to scan a directory for a file and not care what the name is.

Assume that the file name generated by the program is random and different every time - mabey EQW could can a directory for the newest file in the directory that way it always picks up on the new keyfile without having to have a specific name and thus making it easier on the user without having to find the new file every time they zone.

crontab a simple file purge every so often for cleanup and you have a nice way to keep the name of the keyfile random and scarce.

Another neat thing would be a flag in SEQ to say KEYFILE_IS_RANDOM - this would falg SEQ to read the file for a pointer to the key - the rest of the file could be random filler - thus keeping the file size random as well.

I'm just digging into the SEQ source code - er - it's gonna be quite a while before I feel comfortable enough with it to start mucking with it much =(

[octavius]

I have reviewed some of the sniffer code posted here and have seen the use of the OpenProcess function to read the 'eqgame' PID, such as this line used:

hProcess = OpenProcess (PROCESS_ALL_ACCESS, FALSE, pe32.th32ProcessID);

If I remember my windows programming 101, OpenProcess is, in fact, a debug function that will attach the debugger to the process. Now correct me if I'm wrong but the process can not only detect if a debugger has been attached to it, but it can, quite easily with about exactly one line of code, send a message back to SoE that SOMETHING has done a debug read on its PID. It doesn't make ANY difference what you call the program that is sniffing AT ALL. All SoE has to do is determine that some program has done a debug read and then it's all over.

Simply put, the EQGAME process monitors any debug reads to itself. If one happens, send a violation message to the server. Viola. If you open the process for read every 2.5 minutes or whatever to get the current decrypt key, your process will notify SoE that a suspicious process read is occurring every 2.5 minutes.

When I get some time today I'll look up the debugger function calls and show the source code that Verant could use to send a warning message back to the server based off of defeating the existing sniffer code I have reviewed.

[UncleBen]

any more info?

[baelang]

tons of discussion on the point of the debug mode in other threads.

From those discussions, it dosen't seem to be a problem. eqgame has no way of knowing if some external program read its memory space unless it locks the memory segment, which it cannot do because it too needs to access the key.

[UncleBen]

excellent :)

sorry I missed that info, but I do seem to read for like 2 hours everytime I post a question; hehe

The fear of flames here can make you so smart :p

[EQDoze]

You're still grabbing at straws here. There is no 100% "safe" way to grab the key other than to simply not do it. The simple fact of the matter is Sony will cover the most obvious first (as stated by Rowyl in IRC -- aka Patrick). The most obvious are detectable memory accesses. This is, in fact, quite trivial. The only code that needs to be added that would require any depth would be the code that fires off a packet to Sony indicating that memory has been accessed.

The detection is precise enough to tell them that you're looking at a specific offset. If you want to "mimic" the behavior of virus scanners, and memory defrag programs, you can't use the offset in the memory read. I think going directly to that offset is pretty obvious to them.

What might be safer is copying a chunk of memory and accessing that offset on the linux box instead (in a file).


Bottom line is virus/memory scanners do not access process memory for a specific size at a specific address.

[mvern]

I'm kinda curious about this - what simple and non-invasive method can be used to tell that a specific offset of a process' memory is read, normaly?

[MisterSpock]

To be honest, I'm a little curious about the same thing.

I've been doing a lot of reading and had many discussions of this issue recently... I don't believe it is trivial in the least for a process to discover that another process is looking at its memory space.

I also must question -- if it is so trivial, why have they allowed the most egregious cheat programs (which are ALL memory based) to go unchecked for so long? These do far more harm to the game than ShowEQ could EVER do. Yet the only thing that seems to even slow them down is a patch that brings about new offsets.

Why go after SEQ? Because it was an easy target, and far more achievable.

Please, though, do not construe this to mean that we can all be fat, dumb, and happy. We have to remain appropriately cautious.

[EQDoze]

Any memory accesses in Windows go through the MMU (read up on MMU's, Google is a good start). Any computer that uses "Virtual Memory" has an MMU at work. One of the functions of the MMU is also memory protection. If that area of memory is protected, it will generate a "hit", that "hit" gives the precise address that the "hit" occurred at, as well as the size(s) of the read(s). So generating the information that their protected memory was accessed is not terribly difficult.

The specifics about how Windows utilizes the MMU, and the API they provide for it are foreign to me... I only know that Windows does provide memory protection, and that it works like any other MMU -- it traps illegal reads/writes to that memory, and that information can be accessed. It is not invasive to protect memory...

[edit: saw Mister Spock's post a little late]
Heh, that's a great question... why SEQ, why now? Who knows? Just because they can do something, doesn't mean they've had the inclination to at any given point until now. The further I ready up on Windows specific MMU utilization, the more I'm convinced that my concerns are warranted. They're motivated to fight SEQ and other 3rd party "tools" now, which is obvious by Rowyl's gloating...



So, as I said previously, a direct hit to the specific offset is glaringly obvious, whereas a read of a huge chunk of memory is not...

[Jel321]

How bout this for a theory. Im sure someone will correct me if Im mistaken about anything.

What really started this whole thing? PoP comes out and they move from 32 bit to 64 bit. I don't think this surprised anyone since i believe something like this has happend with the release of each expansion. What really changed it this time was the fact that a compression of the packets made it impossible to pull the key from them.

Rowyl comes into an IRC chat-room and the question is posed: "Why the change?" He simply answers "To break ShowEQ" Everyone gets all crazy.

Now, Im wondering if breaking SEQ was the only, or the real reason for the compression. This is the part where someone can correct me..

Compressing the packets reduces their size. This in turn lowers the amount of data the SoE is sending and probably leads to less bandwidth charges. Thinking about the amount of data that they send out even a very small sized change in the packets would result in a huge savings for them. Of course a side of effect of this is that it will break SEQ. Rowyl knows this and decides to come mess with the SEQ users.

I can't help thinking that SEQ being broken was a side effect, not the main intention of the added packet compression.

[EQDoze]

This is unconfirmed, and it's just my opinion of Rowyl... but... I think they turned on compression for the reasons stated (reduce throughput), and stumbled upon breaking SEQ in the process. Rowyl was way too happy about this, as if he were creative or something. Which leads me to believe it was purely a coincidence. ;)

Regardless, they did it, and ShowEQ is no longer passive. The only thing that could be done to catch you using it before was watching for tell-tale signs; from bee-lining to named mobs, to telling others a mob was up that you couldn't track, to blatantly saying "ShowEQ" in communications.

[suseuser7341]

I was always under the impression that compression was used for the initial zone packet for long time, however they compressed the encryted data, not vice versa like now.

About your MMU hits. I really can not conclude any method that exploits page hits.
There is hardly any way to differ between cache hits from a keysniffer than from EQ itself.
I am currently working on using some methods posted in various links here to circumvent windows memory access methods. Along with some code alterations to avoid a public fingerprint of your keysniffer this will be really hard to detect. Unfortunately it takes time to develop.....

Correct me if I am wrong, before this forum opened I had never read anything about GDT, CR3 register and so on, but right now I am positive that you can remain undetectable, IF you don't post the exact code used but only methods.