Monday, July 20, 2009
Hacking
KMFE: Ok, LLF, so the data Alan left is on this harddrive. I don't know if it's encrypted, but it's hard to get at. We have a program to get at it, but this thing's some 40,000 lines of assembly, no function call conventions, no stack. Just one dense mess. On this floppy.
LLF: Have you run it yet?
KMFE: Yes, but here's the problem. This thing runs on the bare metal. 80386SX, I was told. Could try it on a newer 386, but to avoid debugging ten things at once we got the real thing.
LLF: Nice. Get that on Ebay?
Greg: Of course not. This was in my attic. Dell 320N. Nice piece of brick.
KMFE: LLF, the reason it's lucky Greg had one is that we can't communicate with anyone right now. That includes the internet. So we're stuck with the tools we've got.
LLF: Was the code meant to be run on the 320N?
Greg: I don't know. It seems to run OK.
KMFE: Right, except for one thing. It randomly fails.
LLF: ie it doesn't actually run OK.
KMFE: Well, the puzzle is it fails in a different place each time. 869 seconds, 1106 seconds, and 237 seconds.
LLF: How do you know it fails?
KMFE: The machine resets.
LLF: How do you know that's not functional?
KMFE: We don't. At least I don't. But I checked the floppy and it hasn't changed after a reset, so it would seem to be starting from the same parameters.
LLF: How about the harddisk?
KMFE: There is no harddisk in here.
LLF: Does the 320N have any EEPROM or other persistent memory?
KMFE: I don't know. That's the problem, dammit, we just don't know anything.
Greg: Ah yes, it's "security by obscurity". We all hate it and make fun of it, but it's a nasty thing to get around.
LLF: There's a possibility you haven't considered.
KMFE: I don't doubt that.
LLF: Supposing Alan programmed a random failure into it on purpose, to make it take longer to get the data out. Run it enough times and eventually it will get to the end without failing.
KMFE: That's assuming it's some kind of decay process. God knows where he gets the entropy for the random numbers.
LLF: How much time do we have?
KMFE: I don't know. The bill were in Philadelphia this morning. How long will it take for them to find us and get here? I have no clue. We've got four programmers and not one guy who knows something.
Greg: But LLF, if Alan wanted it to take a long time, it would be so it would become readable after they'd searched his house but before they torched it. But an exponential decay process would have too much variability for that little window.
LLF: Well we don't know it's a decay process, do we? Heck we don't even know it's random; in fact it would be easier for it not to be. I'm sure he could fake a decay process.
Greg: How?
LLF: I don't know I'm not a mathematician, but I bet it could be done.
Greg: No, I mean, how is he getting the new seed each time in runs? In fact, even if it is a bug, something is still different each time. Which is starting to look like a hardware problem.
KMFE: Well if we had any other hardware maybe we could deal with it. We don't even know we have the right machine.
LLF: Wait KMFE, what did you mean there's no harddisk? Isn't the encrypted/obfuscated data on that harddisk?
KMFE: Oh sorry, I meant no internal harddisk. This one's read only. And I checked it after a reset - no changes.
Greg: Well something's changing. It might be as simple as running the floppy drive and timing it for the seed. But we're never going to be able to inspect this code.
LLF: Is there an emulator for the 386SX?
KMFE: I doubt it, and even if there is, we have no way of getting it. We can try it on a newer 386, though.
Greg: Man, I wish we could have two of these running at once. First, because I want to see it fail a few more times and see what the distribution of running times looks like. Second, if LLF is right and the failure is intentional, then we might get lucky and it will work.
KMFE: Well it needs to read it over the serial port. We only have one serial harddisk. I suppose we could try to simulate it on the newer PC. But the simulation would be a newer x86.
LLF: Man, you guys, you don't have anything.
KMFE: That's the problem with programmers. Everything's so easy to simulate on modern hardware. Put em in front of a real computer and they don't know what to do.
LLF: But look, if you're going to try to simulate it, could you tweak it?
KMFE: Tweak it how?
LLF: Well, if it's reading from the harddisk over the serial port it knows something about the hardware. But we don't know anything about the hardware. If the 320N is wrong then we'll never get it right. So it may be our only option is to fiddle with the running environment.
Greg: I can try to set something up in an emulator. But I wouldn't know where to begin 'tweaking'.
LLF: Can you run it in a debugger?
Greg: I don't see what use that would do. Can't do a stack trace with no stack, and we don't know where to begin looking at this code.
KMFE: Well how much control do you have over the simulation?
Greg: What specifically are you looking for?
KMFE: Well, some processor instruction is ultimately causing a reset. And some other instructions are getting it there. Can you tweak the behavior of the simulated processor?
Greg: I don't like where this is going. But... maybe.
KMFE: Because we can't rewrite the whole code, or we wouldn't be in this position in the first place. But we could 'rewrite' parts of it in a sense, by changing the behavior of the hardware. And we could see what instructions are being executed right before the reset if we ran it through a debugger.
LLF: How likely is it going to matter which x86 it runs on?
KMFE: I honestly have no clue. I'm an applications programmer. What'll probably change are the IO addresses for various chunks of the hardware.
Greg: Which would kill it outright, depending on how Alan wrote it.
LLF: In other words we still have no clue what we're doing.
KMFE: Dead on, LLF.
Greg: All right, I'm going to set up a simulated i586. Let me know if you have any new ideas.
KMFE: You might be interested to know it just failed at 632 seconds.
LΟF: Which happens to be yet another multiple of 79.
KMFE: Coincidence?
LLF: If it's exponential with a time constant around 700 seconds, you'd almost never get a gcd as big as 79.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment