Saved Bookmarks
| 1. |
Solve : Getkey.com Oddity? |
|
Answer» I'm not quite sure why this is (it hasn't happened on my other computer before) but when I use getkey.com in my code, I get a "File not found" error. It appears that the error actually comes from getkey. I don't have getkey.you should look carefully at the batch script again.oh, YES. It does work fine. Now I have getkey.com and now that I have it, what will I do with it?why do you want to run code that you don't understand? That is some obscure batch/DOS HACK (to hide password entry) that i, for one, would not want to maintain. Also, don't ever use batch to prompt for password. Its useless. Whoever can open the batch file can bypass this.I suggest you use START / RUN / CMD.EXE Then make its home directory wherever your script is. 1. Use DIR and confirm that getkey.com exists there as expected. a) Perhaps for some reason when you ran the script the output went to a different folder / partition / drive. b) Perhaps you have some security protection which quarantines or blocks any executable created by a batch script. 2. Assuming that getkey exists, how big is it. I find that by default it is exactly 137 bytes on my system - THE NON-DEFAULT ALTERNATIVE IS 274 BYTES. By default my CMD.EXE starts life in ANSI output mode, but when I put on the command line CMD /U I get Code: [Select]C:\Documents and Settings\Dad>CMD /U Microsoft Windows XP [Version 5.1.2600] (C) Copyright 1985-2001 Microsoft Corp. C:\Documents and Settings\Dad>and now when this runs the script (which is still ANSI) the redirected output is in UNICODE which is twice as long. To see the options for launching CMD.EXE invoke CMD /? It says a lot about "extensions", and also about registry keys that control it. Perhaps there is something special about your system that caused your script to be executed in Unicode mode. N.B. It is possible your that when your script is executed, the system defaults may cause UNICODE/ANSI output when you execute by a double click in Windows Explorer, and the converse ANSI/UNICODE when you invoke the script from the command line of CMD.EXE launched from START / RUN. No way will I try to run a unicode variant of getkey.com - it may give the error you have seen, or it may do unlimited damage. A few decades AGO I had a DOS 3.ish machine with high powered tools EDLIN and DEBUG. I was comfortable at that time to use EDLIN and DEBUG to create and adjust things like getkey.com. I had a 1 inch thick stack of fanfolded printer listing with all the entry points into the DOS OPERATING System, and also all the special places in the BIOS. I remember there were magic numbers that could be used with DEBUG to launch the BIOS into a format of the Hard Drive to alter the size of the sectors and the number of sectors per track - BUT I ALWAYS CHICKENED OUT. I am astonished that the "magic numbers" that are redirected into the getkey.com file still do in Windows XP and CMD.EXE what they used to do in DOS command.com. Do all the ancient EDLIN scripts for hundreds of old COM things still work as well for XP, how about Vista and Windows 7, and what about Windows 8 ? Alan Quote from: ghostdog74 on January 08, 2011, 01:30:02 AM why do you want to run code that you don't understand? That is some obscure batch/DOS hack (to hide password entry) that i, for one, would not want to maintain. Also, don't ever use batch to prompt for password. Its useless. Whoever can open the batch file can bypass this.I used it before (on my desktop) so that the user could press a button and the script would respond depending on which button was pressed. It would work as a password type script, but not well. @ALAN Yes, it does exist. I check on my desktop and with DIR. It is also 137 bytes and 4,096 bytes on disk. I'm just going to restate something - It's GETKEY.COM that gives the File not found error, not the script.These are your mistakes :- You NEVER told us what the error message was, You never said that Getkey ISSUED the error. I had assumed the error message was from the O.S. trying to locate GetKey and failing. Perhaps you should post the exact message. e.g. I have no GetKey and CMD.EXE shows me Code: [Select]D:\_T\D3\Reg\V2>getkey 'getkey' is not recognized as an internal or external command, operable program or batch file. Is that the error message you get ? Are you using CMD.EXE or COMMAND.COM ? The other possibility is that getkey.com is using magic hex values to work its voodoo, and it assumes that various subroutines will be accessible at certain special places. Perhaps (as I always feared) these subroutines may be missing or in slightly different locations, possibly as a special tweak by the Laptop maker to make way for battery power management ? Regards Alan Helpmeh: can you copy a version of the getkey program as created on the machine where it works to the one where it doesn't or perform a file compare between them? Quote from: ALAN_BR on January 08, 2011, 11:37:00 AM You never said that Getkey ISSUED the error. He said it in the first post "It appears that the error actually comes from getkey." The actual, verbatim message would certainly have been nice. Especially since saying "file not found" came from getkey is sort of vague. Here is the dissasembly of the resulting executable(getkey.com), anyway: Code: [Select] code SEGMENT ASSUME CS:code, DS:code ORG 100h strt: PUSH 3144h POP AX SUB AX,3073h PUSH AX POP DI IMUL [DI+48h],DL PUSH AX XOR [DI+78h],DL INC DI PUSH DI POP AX XOR AL,61h JS J00148 JNS J0014A IMUL [DI+69h],AH INSW OUTSB DB (66h) DB (65h) IMUL [BP+6Bh],CH INSB DB (64h) DB (64h) INSW DB (65h) INSW IMUL [BP+SI+61h],CH OUTSB INSW OUTSB DB (64h) OUTSB POPA DB (64h) INSW OUTSB DB (64h) OUTSB JO J0019B BOUND [BP+0Dh],CH OR CH,[BX+SI+68h] JO J001A3 BOUND [BP+70h],CH INSB PUSH 68h OUTSW J00148: JS J001B9 J0014A: INSB OUTSB PUSH 6961h DB (67h) IMUL [SI+70h],AH INSB INSB OUTSB BOUND [BP+DI+64h],CH OUTSB PUSH 6B6Ch DB (66h) PUSH 666Ch INSB DB (65h) DB (66h) BOUND [SI+66h],CH DB (66h) POPA PUSH 5566h DB (65h) BOUND [SI+66h],AH POPA PUSH 6668h IMUL [BX+6Bh],CH PUSH 0A0Dh INSB DAS PUSH CX OUTSB DEC BX INC BP INC AX DEC AX INC DX XOR SS:[BX+SI+2Eh],CX OR AX,000Ah code ENDS END strt Aside from the fact that this dissassembly is probably different from the actual source assembly (particularly the lack of comments which is not surprising) It pretty difficult to read. As ghostdog said, it's pretty dumb to be accepting passwords in a batch, even if you use a tool like this. It's still in plain text after all, so anybody can get the password simply by viewing the file. Oftentimes a "defense" for this is that "well, they probably won't look in the file" That's a rather weak defense of it. Basically: the above is a mess of Assembly that only works on 16-bit operating systems or systems that can emulate 16-bit. I know this because 64-bit doesn't emulate 16-bit (except via a VM where it works fine) and it just shows a dialog saying "hey, retard, you can't run 16-bit programs on a 64-bit OS". "But" you say- "I just want to get it working on both machines". Well, then you better learn ASM or get somebody who knows ASM to figure out what the program is doing and how the heck it's causing a "File not found" error. (and perhaps explain that error a little better, is it simply "File not found" or does it give the error ALAN_BR describes? In the latter case it's not getkey.com issuing the error at all so you've been accidentally tossing out that red herring the whole time without realizing it. Quote No way will I try to run a unicode variant of getkey.com - it may give the error you have seen, or it may do unlimited damage.No MATTER how carefully crafted the ASM, the protected nature of the NTVDM (as well as the fact that it is in fact a virtualization environment) it cannot do any sort of damage. (that I can think of) in this case, the "damage" is limited to the corrupted getkey.com (which is virtually the same as the original with a null byte thrown in every while) just sorta throws the cursor AROUND randomly in the DOS window until you stop it. Which is actually pretty extraordinary, since most of the time when you run some semirandom bit of faff as code it just barfs out a illegal operation: Invalid Instruction pretty early on. It's probably because all it does is pad in a bunch of zeros which are somehow valid, or something. -With the NTVDM, "dangerous" instructions (like directly accessing the hard disk) will cause faults and the DOS executable will be forced closed. (not always the case for 9x, though, since it truly runs on a DOS subsystem, although 9x is still pretty heady when it comes to DOS programs messing about with FAT32 or VFAT drives and complains about Long file name preservations and whatnot. Quote A few decades ago I had a DOS 3.ish machine with high powered tools EDLIN and DEBUG.I wouldn't really call a cheap assembler "high power", especially compared to the various other assemblers available at the time. I'd be more inclined to say "useful" in the same way that a knife is useful to scoop ice cream when you have nothing else, whereas TASM and the other Assemblers where the Ice cream scoops. That being said, the "knife" version was free and while it's a bit annoying to use a knife to scoop ice cream it can be done. in fact on the whole it's weird(cool) that they included something like that(debug, I mean)- but it certainly was useful. Come to think of it though a lot of what people were doing with DEBUG could be just as easily done in BASICA, which was included with early versions as well. (OTOH, you can't run BASICA programs now because (for space reasons) it's default save format was binary. I couldn't remember if DEBUG let you use actual ASM or just the hexcodes- so I checked it let's you use ASM, which is useful, but only the most basic instructions... (which was enough for things like determining wether SHARE was running: Code: [Select]N ISSHARE.COM A 100 MOV AX,10000 INT 2F MOV AH 4C INT 21 R CX 9 W Q which you could save to a file and then save to debug. Code: [Select]DEBUG<ISSHARE.ASM and POOF! you have ISSHARE.COM. Anyway, best you could do was essentially the "Magic numbers" thing. Throw values into specific memory locations, call an interrupt, and then inspect the same random locations or possibly some other set of random locations. Thing is, it is extremely low level; even though the memory locations can be found by looking through it, these memory locations often have nothing to do with DOS itself and more to do with inspecting other programs (for example, wether SHARE is loaded). Interestingly enough, the "ISSHARE" ASM program broke fairly quickly, when MS integrated the DOS SHARE redirector right into windows for workgroups; the debug script result basically looks in specific locations that it knows that SHARE messes about with and should contain certain values, but SHARE.VXD didn't so it pretended it wasn't loaded. Quote I had a 1 inch thick stack of fanfolded printer listing with all the entry points into the DOS Operating System, and also all the special places in the BIOS.Probably would have been better to get the actual manuals, rather then printing out some stuff from BBS's -I mean no offense of course, but that is a rather small stack, (no doubt useful, but perhaps too concise) and (of course your memory may have faded with time, so they may well have gotten the following correct) "DOS entry points" are called "DOS interrupts" and "special places in the BIOS" could be any number of things (but generally also BIOS interrupts) Mostly the important bits were the Interrupts, and each interrupt usually used the various Registers to perform tasks. (I have no idea how debug puts stuff in the registers, or even if it could) Quote I remember there were magic numbers that could be used with DEBUG to launch the BIOS into a format of the Hard Drive to alter the size of the sectors and the number of sectors per track - BUT I ALWAYS CHICKENED OUT.Interrupt 13H. Not sure why you'd chicken out... of course it would be silly to expect a drive format to preserve the data, but the worst case scenario would probably be having to format again afterwards. (of course, if you thought that it would simply change the format without formatting the drive itself then it's a good thing you decided not too! Quote I am astonished that the "magic numbers" that are redirected into the getkey.com file still do in Windows XP and CMD.EXE what they used to do in DOS command.com.pretty much all the script does is move the cursor around and accept a bit of input. the NTVDM was practically designed specifically to let 16-bit programs like that work. Quote Do all the ancient EDLIN scripts for hundreds of old COM things still work as well for XP, how about Vista and Windows 7, and what about Windows 8 ?depends what they do. Any x64 (or IA-64) OS isn't going to run the COM files anyway; 32-bit versions will run them with limitations, some interrupts are entirely off-limits (such as I believe everything in 13H) in fact those were even limited to some degree by windows 9x) some others just cause the NTVDM to say the program performed an illegal operation and will be terminated. Windows 8 is purported (I doubt it though) to be 64-bit only and if that's the case it won't be able to run any 16-bit software at all. BC, the dissembler is if little value. We need the real source code to see what went wrong. Does anybody else here really want the original source code? Is it available? |
|