Riddle me this batman

[Tumpy_Irontoe]

<>This is all Theroy I am not going to say I have all the details hammered out and what not but this is my idea.<>


Okay why couldn't you build a device that link up to the RAM of the everquest computer ... like maybe it sit between the RAM and the ram slot (kinda like a gameshark type device) and it allowed the linux box to link up (maybe via an open ram slot or something pretty fast... firewire?) Where as you could read the RAM or atleast the data going to and fro the ram of the windows box. That way you could get the key via that method and be baiscly again un-decetable again by SoE..... Ideas, comment, suggestion?

[Ratt]

Let us know when it's finished and where to buy it. I'll buy one.

[Tumpy_Irontoe]

I have gone over the idea a few times and don't have a lot of knowledge of this exactly, so if anyone wants to a) build it or b) give me ideas on exactly what I should do or c) steal the idea patent it and sue me. go ahead hehe :) I do think that this idea shouldn't go to waste though. I have messed a bit with DTV hacks and thats where I am getting ideas from now hehe

[arantius]

Back (way back..) when I was starting to move past programming in Basic, my dad told me that I was dangerously intelligent. That meaning, I knew only enough to be dangerous. Enough to come up with lots of wild ideas without the slightest clue how to follow them through .....

[Jonn]

certainly something that's never occurred to me before. I think on a highly technical level though that it wouldn't work. I know quite a bit about computer hardware on a low level (not talking about simply differences between RAM types, and stuff like that, but the actual workings of the circuitry and how it interlinks, searching for previous posts by me will likely reveal what I mean by that), but I admit I don't know that much about this specifically.

Realalistically, I have to think that what you're proposing isn't actually possible. It really sounds good in my brain, but accessing the memory of a running Windows application is about 3 orders of magnitude easier than locating that memory in what ammounts to a physical RAM dump. Putting aside the concerns over the fact that RAM access is already considerably faster than firewire, or any other cabled data transfer, I think that given the fact that Windows virtual memory space tends to fracture... a lot... would make this a completely daunting task. If you can avail yourself of builtin Windows API to locate memory in virtual address space, this is far easier, but with only physical access to RAM, you don't have that luxury.

Let me try to explain what fragmented memory means. Lets say you start 3 applications, a, b, and c. Each takes 3 units of memory, so your basic memory map looks like this (in a 24 memory unit space, with x's denoting unused memory):
aaabbbcccxxxxxxxxxxxxxxx
Now, program c needs 1 more unit, you get
aaabbbccccxxxxxxxxxxxxxx
now program a needs one more unit, you get
aaabbbccccaxxxxxxxxxxxxx
As far as program a is concerned, it's memory space looks like this:
aaaa
even though it's broken up within memory. OS's address that with virtual memory lookup tables. Physical memory addresses are, lets say, 4 digits in this artificial model I'm using for an example. The first two digits represent the memory PAGE (in this model, there are 24 pages, or 24 units of memory), and the second two represent memory within that page, which we'll say is also broken down in to 24 units. These sub-page units are physical bytes of RAM, so in our 24x24 memory model here, we have 576 bytes of RAM: 24 pages of 24 bytes. Programs requesting additional memory have to request an entire new page, they cannot request anything smaller.

Program A has the pages
00xx
01xx
02xx
10xx
Program B has the pages
03xx
04xx
05xx
Program C has the pages
06xx
07xx
08xx
09xx
all with respect to physical memory. The x's represent the 00-23 bytes within that page of this model.

But program a might have one block of data that spans from 0220 for 24 pages, so the end of the memory ends up in 1019, with a gap in the middle. The program shouldn't have to rely on managing that divide. So instead what happens is that the OS manages that with memory space lookup tables, or virtual memory space mappings.

Program a only needs to concern itself with its own representation of its memory, which is 00xx through 03xx, as it has 4 pages. The OS keeps a table for program a:
00->00
01->01
02->02
03->10
It swaps out the first two digits of program a's virtual memory space with the two digits found in the table, so that when program a requests 0319 (the end of the memory block we talked about earlier), the OS translates it to 1019.

Program b's table looks like this:
00->03
01->04
02->05

and program c's table looks like this:
00->06
01->07
02->08
03->09

So any time a program requests data, it does so based on 0 being the beginning of its memory, contiguously. The OS uses that lookup table to quickly translate the memory to its actual location.

Lets consider that we now kill program b. Our memory space looks like this:
aaaxxxccccaxxxxxxxxxxxxx
Now a requests another page:
aaaaxxccccaxxxxxxxxxxxxx
and c requets another page:
aaaacxccccaxxxxxxxxxxxxx

program a's table is
00->00
01->01
02->02
03->10
04->03

and program c's table is
00->06
01->07
02->08
03->09
04->04

Now it seems like it wouldn't be too hard to manage that as a piece of software attempting to dig data out of raw memory, but stop for a second and think, these lookup tables have to be put in memory with the application code. Each program that starts has a block of header information before it gets to the actual data that it administers. So our model would actually look more like
XXXXAAaaaBBbbbCCcccxxxx
from the start, and at the end:
XXXXAAaaaacxxxCCccccaxxx
where capitol letters indicating programatic header, static code lookup tables, and whatever else needs to be maintained with the program, and capitol X's where the OS is keeping track of information about the actual processes, its kernel space, etc.

You have to break this all apart, and figure out where the kernel is keeping what. Difficult? Perhaps [this difficulty is a big part of why OS's aren't the sort of thing most people do in their spare time], but definately doable [someone did so for any OS that's out there]. But the real catcher is that any different OS, or different version of an OS can do all of this differently. The basic concepts are the same, but with out specific working knowledge of the structure of program and kernel headers, you can't build an application to reconstruct this.

Because there are so many things you can do to increase performance for this stuff, many new versions of OS's change their structures. There are so many page sizes, so many header sizes, so many kernel sizes, and each kernel for each os will almost guaranteed do something a little different from other kernels. They don't need to be reverse compatible, they only need to be compatible with their own current version, as only one OS will be resident in memory at a time (until we get in to the whole idea of servers that host virtual space OS's, which basically treat the OS like a program of its own, but we won't throw that monkey wrench in here). All of this complexity is why there are API's to access this information. These function calls are tailor-written for the specific kernel version.

So what you end up with is a program that needs to interpret this data differently for each version of the Windows kernel. Again, doable and yet more complex, but all of this can take significant searching around through memory. Lets get back to the hardware issue. Firewire, fiber optics, whatever, don't measure up to the performance of memory, if they did, then that would be the technology by which your computer used to talk to its RAM. So you're back to needing to communicate heavily over a narrow pipe.

So really cool idea, and if you were an FBI hacker who was trying to break into Iraqi systems, then it's probably something that's worth the amount of effort required, but in any commercial role, the expense of doing this (the hundreds of thousands of dollars) simply isn't worth it.

[malakai]

Originally posted by Jonn
... but in any commercial role, the expense of doing this (the hundreds of thousands of dollars) simply isn't worth it.

Jesus, I don't think the post was worth the expense/time you took to form a response.
-malakai

[steppuppy]

yeah far to large of a post to say it cant be done.

[Jonn]

*shrug*

if you want to know how things work, read it, if not, don't. Up to you.

[Cryonic]

That is a lot better than some random person that none of us know (how many of you know me?) just saying "Can't be done". Always better to see why.