Shagghie wrote: > Jure Sah- > Thanks! Your names/handles are a WRETCHEDLY UNGUESSABLE FJORD..... but > I've attached a photo so at least you know what you look like. > > Very fitting that a fjord is a " a narrow inlet of the sea between cliffs or > steep slopes".... =P > How did you do that so fast? I will tell you. Before running it, I've checked it with the program "Dependency Walker" (which kinda comes with Visual Studio). That program lists all the DLLs, OCXs and other components used by the EXE without actualy oppening it. The most immediate file refferenced to was the Visual Basic 5.0 runtime module, so go figure what was my first guess. =P I quickly reviewed the other modules refferenced too (Visual Basic programs cannot load additional DLLs or other external procedures durring runtime, so all of the modules were directly obvious without the need to profile the running program) and there were no modules involving the internet, or modifying the registry or anything one could consider dangerous. Second, I copied the program to a floppy and used a very very very old DOS program, a simple Hex editor (hex editors are programs with practicaly zero features other than disk reading and writing plus display, but a one that works is the cracker's paradise). This particular hex editor is incompatible with modern computers, so I had to work with a floppy, but it quite successfully displays EXE binaries and the ASCII text parts of it. I am an Assembly programer and I know that programs store their pre-defined data in original format somewhere at the end of the code. Visual Basic in particular stores it's pre-defined data in doubled bytes (so "ABC" in source code is "A(null)B(null)C(null)" in the actual EXE). So basicaly, I opened the file in the hex-editor and simply read the texts out of the program. Having determined the program is harmless (Visual Basic runtime module has it's procedure names in plain text so things like "_VarAdd", otherwise the variable addition operation were all over the EXE), I ran it and determined what how it responds to my interaction. Given that this procedure is pretty complex, I have made a mixed-language program, that will open the EXE or any other binary file and make a text file out of it that contains all the filenames and anything you ask it to extract. If you plan to be curious about more programs, I can dig it up from the archives and send it to you. > I need to admit something basic here....I'm a network guy, not a programmer > (a hack at best)... I'm a low-level computer programmer, you could say old-school programmer. I'm not quite up to date with Microsoft's latest tricks of the Database, nor am I a "C++ supremacy" enthusiast, but I basicaly know how to crack down a copyright message or make a program that, when windows tries to display it's icon, preforms some random operation that I had in mind. And, in case you were wondering, I don't do cracking or hacking, I am a computer programmer for a company that makes bioreactors (t.i. incubators for microorganisms) and their control hardware/software. > What a neat analysis! What makes the user/pass not obvious? encoding? > cipher? md5? It is not in the previously mentioned doubled bytes format, that's all. I do not know the encoding really, but I have no idea why you would want a correct password in a program that does nothing? Is the password used for something else? Well I guess I don't need to know. > I have a copy of MS Visual Studio, but, don't laugh, I can't seem to 'open' > or work with the .exe file in it to take it apart. > Is this the wrong tool? I'd say so. > If so, do you recommend another that would be > sufficient for me to find the user/pass? I only have access to win2k /winxp > platforms here at work, so they'd have to be m$ friendly. Ugh.... Well I don't personaly work with anything besides Microsoft-compatibles (I just feel that Linux is part of the "C++ supremacy" movement and thus never got too excited about actualy using it). Why I say "ugh" is because what you'd really need is an expert, not a program. =P But I think we can work with what we got if it's really important. All I can tell you about the password is that the program uses the most basic mathematical and string manipulation methods to decode it. Visual Basic 5.0 programs can't really be decompiled, I can try running the program trough a dissassembler (a program that changes an EXE program into Assembly code) and interpret that, but this will surely fail if it is true (as I suppose) that Visual Basic 5.0 compiled programs work all in all trough the runtime DLL and consider the majority of their code as data for the DLL and not as CPU instructions. If this works, we should be able to isolate the encoded username and password from the other data in the program. After that, we can try to decode them. P.S.: The shift decoder you've mentioed is actualy... hehe... another program than the one I had in mind. You should perhaps try to mention what newsgroup you've found the post in next time. ;) The shift decoder can decode practicaly any linear shift and it was made to detect the decoding key automaticaly. I've made it because I needed to hide my porn from my parents and kept forgetting what the decoding key was. ;P If you want the proggy I think I can give it a user interface and send it to you, but note that it's a DOS program (should run fine in a DOS box in windows). > shagghie > "sometimes, the dragon wins"... -- I could run like the wind just to be with you. Observer aka DustWolf aka CyberLegend aka Jure Sah C'ya! -- Cellphone: +38640809676 (SMS enabled) Don't feel bad about asking/telling me anything, I will always gladly reply. "Yes, Master." Have you been told Internet will always be threatened by worms viruses etc? We don't think so: http://208.186.111.189/ici/index.htm MesonAI -- If nobody else wants to do it, why shouldn't we?(TM)