Reverse Code Engineering RCE CD +sandman 2000

home *** CD-ROM | disk | FTP | other *** search

/ Reverse Code Engineering RCE CD +sandman 2000 / ReverseCodeEngineeringRceCdsandman2000.iso / RCE / Library / +HCU / 181-190.TXT < prev next >

Wrap

Text File | 2000-05-25 | 56KB | 1,462 lines

======================================================== +HCU Maillist Issue: 181 03/31/1998 -------------------------------------------------------- Send Articles To:......................... ************* Info, Help, Unsubscription, etc:....... **************** Web Repository.........................hcuml.home.ml.org ======================================================== CONTENTS: #1 Subject: Re: OpenNT 2.1 #2 Subject: freespace crack ARTICLES: -----#1------------------------------------------------- Subject: Re: OpenNT 2.1 Hi, first I have uses a sig but it was stipped off... However, it should have read Muso. In the future will include it at the top of the posting. Sorry for that. Back to OpenNT 2.1: I will get this 'wisdec' tool and have a closer look at the install- script. Ghiribizzo stated the 'conventional' way... well, many ways maybe 'conventional' but the only way to go, I think, is to make a new key-generator for it. The license checking is splattered through all the code not only the installation stuff... a valid license key is of course the most sofisticated solution ;-)) -----#2------------------------------------------------- Subject: freespace crack Hello all, remember freespace? somebody asked for a crack for it. Well, I haven't got the time to crack. I made a little search on the web, and there seem to be cracks for it. Anyway, I decided to buy the program, and I upped it to a web site for you all to fetch - but I will remove it in a few days. the file is ***************************** after you downloaded it, rename it to fs10.exe enjoy. WAFNA =====End of Issue 181=================================== ======================================================== +HCU Maillist Issue: 182 04/01/1998 -------------------------------------------------------- Send Articles To:......................... ************* Info, Help, Unsubscription, etc:....... **************** Web Repository.........................hcuml.home.ml.org ======================================================== CONTENTS: #1 Subject: OpenNT 2.1 ARTICLES: -----#1------------------------------------------------- Subject: OpenNT 2.1 Hi everybody it's Muso again with the OpenNT stuff. As Ghiribizzo suggested I did disassemble the install-shield script: Here is (as Ghiribizzo stated) the relevant part: 000079BF: 0128 IF (StrCompare (StrLocal[0004],"") != 00000000) THEN 000079DF: 00B4 NumLocal[0005] = MYDLL.verifyKey (StrLocal[0004]) 000079F7: 006E NumToStr (StrLocal[0002],NumLocal[0005]) 000079FF: 00B4 NumVar[004A] = MYDLL.whatIsThis (StrLocal[0004]) 00007A17: 0128 NumVar[0056] = NumLocal[0005] = 00000000 00007A29: 0128 NumVar[0057] = NumVar[004A] = 0000012D 00007A3B: 0128 NumVar[0058] = NumVar[004A] = 0000012E 00007A4D: 0126 NumVar[0059] = NumVar[0057] || NumVar[0058] 00007A58: 0128 NumVar[0057] = NumVar[004A] = 0000012F 00007A6A: 0126 NumVar[0058] = NumVar[0059] || NumVar[0057] 00007A75: 0128 NumVar[0057] = NumVar[004A] = 00000130 00007A87: 0126 NumVar[0059] = NumVar[0058] || NumVar[0057] 00007A9D: 0022 IF (NumVar[0056] && NumVar[0059] != 00000000) THEN 00007AAB: 0021 NumLocal[0002] = 00000001 00007AB5: 0013 StrLocal[0008] = StrLocal[0004] 00007AD5: 0128 IF (MYDLL.isDemoKey (StrLocal[0008]) = 00000001) THEN 00007AF5: 0021 NumVar[0041] = 00000001 00007AFF: 0021 NumVar[0042] = 00000001 00007B00: 0000 ENDIF 00007B11: 0000 ELSE 00007B1A: 0021 NumLocal[0002] = 00000000 00007B24: 0091 CtrlSetText (StrLocal[0001],000003E8,"") 00007B31: 0013 StrLocal[000A] = "Workstation/Server Key Invalid" 00007B32: 0000 ENDIF 00007B60: 0000 ELSE 00007B69: 0021 NumLocal[0002] = 00000001 00007B6A: 0000 ENDIF So what do they do here? They call there verifyKey() function with the key-string (BTW: The compiler says that the signature needs a second parameter but the function is only called with one). Than there are some tweaking with the bits etc. and finally the decision is made by the compare: 00007A9D: 0022 IF (NumVar[0056] && NumVar[0059] != 00000000) THEN This one is interesting because NumVar[0056] holds the return value of verifyKey() and verifyKey() is (was in OpenNT 2) returning 0 for a valid key and 1 for an invalid one. But with a 0 this if never gets true !??? Very strange. Either verifyKey() is returning something different than 0/1 (I tried it with a long and it's still 0) or the verifyKey() function can recognize the 2.0 calling convention and if so returns a fake OK for a 2.0 valid key if it's a 2.0 valid key. For a 2.1 valid key the retur nvalue is something different (like a Pointer etc.) What's very strange too is the call to NumToStr between the verifyKey() and whatIsThis() call. For me it doesn't make sense here... Does anybody else has a suggestion how to =====End of Issue 182=================================== ======================================================== +HCU Maillist Issue: 183 04/03/1998 -------------------------------------------------------- Send Articles To:......................... ************* Info, Help, Unsubscription, etc:....... **************** Web Repository.........................hcuml.home.ml.org ======================================================== CONTENTS: #1 Subject: ICQ privacy question ARTICLES: -----#1------------------------------------------------- Subject: ICQ privacy question Hello all, In Issue 175, Zipper49 asked about ICQ security. I stumbled across this exploit tonight. Just food for thought. ************************************************************** =====End of Issue 183=================================== ======================================================== +HCU Maillist Issue: 184 04/04/1998 -------------------------------------------------------- Send Articles To:......................... ************* Info, Help, Unsubscription, etc:....... **************** Web Repository.........................hcuml.home.ml.org ======================================================== CONTENTS: #1 Subject: "Your PC spies on you" ARTICLES: -----#1------------------------------------------------- Subject: "Your PC spies on you" "Your PC spies on you". Under this title the French magazine "SWM" (price: 29FF; adress: 1, rue du Colonel Pierre Avia, 75503 Paris; tel 0146484708)to pvlished several articles in its latest April issue (pp.63-77). For those who are not able to consult it, here is the summary: "Who commits a computer crime, will be trapped by computers". "HD has a long memory". "You have deleted confidential data on your HD and thus you believe to be protected against information leakage? Be careful! It is much easier to burn a letter than to definitly destroy a computer file..." "One can never be sure that deleted HD files are really destroyed. In fact, Windows cuts only the logical access to them, but they continue to exist on the disk...Even if you delete them physically, there are means to recover their traces!". In Europe the experts are: PCM Assistance (Nancy, France) and US company Ontrack (London). Secret services, especially FBI, have their own labs. Many of shareware editors propose to register their products online, via modem. Can they in the meantime spy on our HD to find cracked (or smuggled) versions, or the presence of rival products? Great editors strongly deny that they ever considered such an usage, but admit that technically it is feasible through Windows Registry... Perhaps the safest way is to remain unknown to the editor." "Your Internet provider knows everythyng. For example, all your visited Web sites, time, your real identity, your E-mail (sent and received), all this without any effort, as it is stocked on their server. Of course, all providers will say that they never do such things. 'As a postman can read distributed postcards, so we can do it, but we do not lose the time on such futilities', answered to us provider F." "The visited Web sites know you better than you suppose". The way to arrest a computer. In former times the HD was dismantled and brought to a lab. Not now, because there are certains drivers which can destroy all data at any intrusion. Any access only by diskette, and browse only DOS. And then, as soon as possible, to install a TSR program Wright Block, which prevent any HD data modification. Then a copy of HD is being made; any further research is being made only on that copy. The most powerful research tool is Disk Search. To crack codes and passwords the US company Access Data has developped some tools. The most resistant to investigations is WindowsNT, for DOS reasons. End of quotations. Good and cheap German magazines: PC/DOS Magazin ******************** price 8 DM, and Internet Magazin ************************** price 4.90 DM. Could not find any good cheap US magazine. Let me know if you know any. Can anybody tell me, how to get the book of Tom Swan, "Mastering Turbo Debugger",Paperback, published 1995, out of print ? End. AZ111. =====End of Issue 184=================================== ======================================================== +HCU Maillist Issue: 185 04/05/1998 -------------------------------------------------------- Send Articles To:......................... ************* Info, Help, Unsubscription, etc:....... **************** Web Repository.........................hcuml.home.ml.org ======================================================== CONTENTS: #1 Subject: assembly book ARTICLES: -----#1------------------------------------------------- Subject: assembly book >Can anybody tell me, how to get the book of Tom Swan, >"Mastering Turbo Debugger",Paperback, published 1995, out of print ? >End. AZ111. > I believe you are referring to "Mastering Turbo Assembler", a book published by SAMS press for about US$45. Here it is from Amazon: ***************************************************************************************** and here is a tutorial I just came across based on the book: ********************************************** Now this looks like an excellent book. I have seen a couple of copies in mainstream bookstores (those with good computer sections, at least) so it should not be too hard to find, even if out of print. As I have so many assembly books I decided for once to just wait for the new edition before I pick up a copy :) _m ______________________________________________________ Get Your Private, Free Email at ********************** =====End of Issue 185=================================== ======================================================== +HCU Maillist Issue: 186 04/06/1998 -------------------------------------------------------- Send Articles To:......................... ************* Info, Help, Unsubscription, etc:....... **************** Web Repository.........................hcuml.home.ml.org ======================================================== CONTENTS: #1 Subject: gthorne - regarding computer deletion and lack of security ARTICLES: -----#1------------------------------------------------- Subject: gthorne - regarding computer deletion and lack of security Message Body = on considering the article posted regarding pc spying on you - and its references to how difficult it is to hide data from 'data' prosecutors, is it any wonder why the US military (probably in the TEMPEST specification on comupter security) only considers a hard drive clean after being overwritten 7 times completely with zeroes? +gthorne =====End of Issue 186=================================== ======================================================== +HCU Maillist Issue: 187 04/07/1998 -------------------------------------------------------- Send Articles To:......................... ************* Info, Help, Unsubscription, etc:....... **************** Web Repository.........................hcuml.home.ml.org ======================================================== CONTENTS: #1 Subject: data evidence #2 Subject: In memory patching - final :) #3 Subject: re: Assembly book #4 Subject: Re: Assembly Books #5 Subject: Fravia's Page ARTICLES: -----#1------------------------------------------------- Subject: data evidence >is it any wonder why the US military (probably in the TEMPEST specification on >comupter security) only considers a hard drive clean after being overwritten 7 >times completely with zeroes? I thought the tempest specs were just regarding e-m radiations from computers? In any case the overwriting with zero/ones is just for non-confidential data. I suspect more paranoid measures are taken with sensitive data which would mean an unusable hard disk.. well, what's left of it :) I amazed a friend a while back when I unerased a file. He thought that when you erased it was gone forever. I'm sure you all know that dos just overwrites the first character of the filename with a special marker to show that it has been deleted. If you didn't know this try deleting a file and manually undeleting it using a disk editor. Also, even overwritten data can be recovered (with the right hardware) as the heads on the hard disk aren't exact so residual magnetic traces can be left behind. The idea of multiple overwrites is to hopefully make sure that most of the original data has been wiped. I'm not sure what the tempest specs were written for as I find it hard to believe that you can mask the e/m emissions from a computer completely just by using special monitors and cabling etc. It reminds me of an article I read (in New Scientist - I think) a few months/years (my memory isn't what it used to be!) back about the US embassy in Moscow. I think they called it the greatest monument to espionage. They believe the cost of the bugs inside the building are worth more than the building itself! The Americans made the mistake of getting local labour to make some of the wall panels (or something like that) and they ended up with hundreds of bugs in each panel. The taps were wired and bugs were sent through the plumbing. I think there was a windowless top floor surronded by a faraday cage to stop e/m snooping - but I think the Americans decided to build another building and use the old one for mundane tasks. ~~ Ghiribizzo -----#2------------------------------------------------- Subject: In memory patching - final :) This is the final edition of my "In memory patching" essay. Most is an exact repost of what I already wrote to this list before. My apologies. Fravia: you can post it on your page - sorry it's not in HTML - I'm one of them HTML challeged crackers :) enjoy, Stone / UCF & F4CG Doc-Start: --------------------- In Memory Patching Three approaches (C) Stone / UCF & F4CG '98 After reading MadMax's essay on kernel patching I decided that perhaps it was time for an essay on "in memory patching". Contrary to the general +HCU philosophy my approach will be purely theoretical - the sourcecode I provide will serve as an example for you to build on. While this document might seem to be relatively technical and advanced it is unfortunately only an introductory text into the wonderful world of abusing windows :) Is something preventing a patch? Is your target encrypted, packed, CRC'ed or you need the program to run sometimes with the patch applied sometimes without (A game-trainer for instance).Wouldn't you just love if you could patch the program in memory after it loaded, unpacked, did the CRC checks etc. ? You can. In the dos days we had TSR's to do this job. In the windows world it's a bit more difficult as the programming interface (Win32 API) is dynamic in contrast to dos's static interupt system. However new methods which in many ways are similar to TSR's are now avaible. Kernel patching as MadMax pointed out is generally a bad idea. We need a more gentle approach. Which critereas would we like our solution to conform to? The critereas I'll use is: 1) The approach should perform ok in terms of compatability. That is work on both NT and 95 and hopefully on future versions as well. 2) The operating system should not suffer any long term effects of the crack. That is after termination of the target the OS should be left unchanged. 3) Only ring 3 meassures should be used. (Some of the API-functions I'll use from ring 3 will actually switch to ring 0, but atleast there will be no foreign code introduced at ring 0) For a discussion of this issue see various issues of HCU ML (Participants: Quine, RCG & myself) Common ground Our immediate problem is that in a preemptive operating system like Windows each process runs in it's own addressing space. Each time that the operating system switches to another process the virtual mapping is changed to fit that of the current process. The whole idea with memory patching is providing means of patching the target in it's addressing space at a certain time (after unpacking, CRC'ing or whatever is done). However since a criterea of the memory patch is that we can't patch the operating system nor the program itself we need to find a way of gaining access to the target addressing space from another processes. The next problem we got is one of timing. Obviously the target needs to be patched after the CRC check has been performed or after it is unpacked in memory. And possibly it needs to be unpatched again to pass later checks. In other words we need a reliable trigger mechanisms. It is in this respect that the three methods I'll present here differ. The loader approach The critical assumption I'll make here is that the USER of the program can tell us how to time the patch thru another program. This basically means we assume that the user can: 1) Identify when patching is appropriate. 2) Switch to another program to activate. About the first assumption it can be said - if it's a trainer this will never be a problem. Obviously the user will know when he want's to have infinate lives. Often a messagebox or some other visable sign shows itself when a patch is needed. E.g. A messagebox saying "Insert correct CD in drive and press OK" - It'd be easy to write a doc saying that when this occurs the dear user should press OK in another window first, and then in the target's obnoxious messagebox. However this is a serious shortcomming. Who said the program will actually let the user make a retry? Most 30-day trials tell the user the program has expired and the just exit or trial mode or whatever. Perhaps many different locations has to be patch at many different time making user-controlled patching a cumbersome solution. On assumption 2 can it be said that many games doesn't like switching tasks and it's not likely that users will enjoy having to switch out of their game to get a new handful of bullets or whatever. Let's get a bit more technical. Windows is so nice to provide us with an interface to write in other processes addressing space. The API needed is: kernel32!WriteProcessMemory If one take a closer look at this you'll find that what it actually does utillize Windows's int 2eh interface to switch to ring 0 meaning that it has ring 0 priveledges and thus is able to override page protection. However the interface has build in a security feature so you cannot override ring 0 data/code. (The int 2eh interface is for NT - I figure Windows 95 does something similar but I havn't checked it. Anyways the result is the same) For WriteProcessMemory to work we need to identify by handle which process we want patched. IMHO the best to find such a handle is to create the target process yourself - that is do a good old fashioned EXEC from within your patch/trainer code. The API is Kernel32!CreateProcessA Ofcause there is different means of finding process handles. To summerize a in-memory-patcher of this kind: CreateProcessA (Target) Wait for the user to say apply patch - e.g. a messagebox WriteProcessMemory Sourcecodes at: ******************************************** (or something) ------------------------------------------------------------------------ - The API-Hook/Debug Approach Obviously the assumptions made for the Loader Approach can be too restrictive. For instance 30-day trials often exit prior to offering the user any obvious point of introducing a patch. So does dongles. Players might not like to switch task out of their beloved game to get another 10 bullets or whatever. What we really need is the target to trigger the patch and this section is a way of doing this. The whole idea here is to hook an API-call, and make it perform to our desire. That can be return fake values under certain circumstances it could be to patch the main program or it's dll's in memory. In short what we wish to do is to let the api-call the program performs be surrounded by our code so that we can make it perform in every way we wish. Certain side benefits will come along as well. That is the code I present will show how it's possible to introduce breakpoints in an automated debugger which is indeed something very useful for the creation of for instance unpackers. Again let's get down to it. A PE-file "imports" the functions it wishes to make use of. Because MS-developers decieded on a dynamic structure for API's it's obviously neasesary for each program to declare what functions it uses. This is done in a so called import table. Let's now take a deeper look into what takes place between the importtable in the PE-file and the execution of an API call by the target. 3 basic types of information is stored in the importtable. The first is DLL names, the second is function names and the third is a Thunk-RVA. The information is stored in a structure that looks something like this: DLL1-Name Function1-from-dll1- name or ordinal Thunk-RVA of Function 1 of DLL 1 Function2-from-1dll-name or ordinal Thunk-RVA of Function 2 of DLL 1 .... DLL2-Name Function1-from-dll2- name or ordinal Thunk-RVA of Function 1 of DLL 2 Function2-from-1dl2-name or ordinal Thunk-RVA of Function 2 of DLL 2 .... ... What Windows does while loading the PE-file is traverse thru this table following this "pseudo code": While more DLL's do { Load DLL into process addressing space While More Functions imported from current DLL do { Find address of Function and write this to the Thunk-VA for this Function } } END Load Imports The function may be listed by name or something called ordinal. In every DLL each function that it exports for use by other programs is listed in an export directory (which is where Windows find the address of the imported function) in this list each DLL is assigned a number and usually a name too. The number is called ordinal. Importing can be done either by referencing this ordinal value or by using the name. What the program then does when it's in need of the API-function it is this: CALL Dword ptr [Thunk VA of needed function] As an unimportant side note it can here be noticed that Borland and old Microsoft Compilers does this perfectly equivilent thing, calling a jmp dword ptr [Thunk VA] instruction. Lets for a second imagine that we could stop execution of the target process right before it started and then inject our own code in to it's addressing space. Then we could simply replace the value at any Thunk-VA with a pointer to our own code and our code would be executed every time the program decieded to use this API. We could even save the old pointer and use this to chain the original intended API-code. Weeeeeee.. "Isn't this just great?" as Oprah Winfrey would say. "No, it is not", as I would reply. We are left with a new problem. Or rather two. The first is stopping Execution of the target process before the program runs the first instruction so that we can be sure that our new pointers are in order. Second we're left the great problem of having code in the target's addressing space. Solving a problem at the time we start by examining how we can stop our target process. Many people always state that Windows is overbloated and perhaps they are right - but in this case I'd say that it's damn convinient that MS-engeneers made a full-featured debug interface while designing API calls so that we could with the greatest of ease program a debugger without having to do the low-level work ourselves. Infact they made it so that not one line of ring 0 code has to be written to make an application debugger. "Isn't this just great?" as Oprah would phrase it? "Yes it is, maam" as I would reply. Because it get's even better. Windows engineers must've actually been thinking the day they made Windows. What good is a full-featured debug interface if the poor programmer has to make a PE-loader before he can even start debugging. Hey after all they already made a loader and they decieded to be helpful. CreateProcessA can open a process in Debug mode. This means that inside of most Windows's procedures hides status breakpoints that'll turn over the control to our debugger thru that interface. One of these status breakpoints triggers just before Windows is about to turn over control to the just loaded PE-file. Convinient! Obviously if a process is in debug mode execution is suspended everytime a debug event occurs. A debug event is any non-handled exception. Pagefaults, breakpoints, division overflows, etc. And there is 6 different types of status breakpoints inside Windows that'll be triggering like Rambo in Iraq. So basically we need to send a message from our debugger process that it's ok to continiue every time we have encountered such an event. Ofcause if it's the event we've been looking for we need to do whatever it is we wish to do before giving the green light to run on. This is the reason behind the loop of kernel32!WaitForDebugEvent and kernel32!ContiniueDebugEvent in my code. So now we know how to stop the program before it actually started. If you read the previous section you'll know how to exchange pointers. This leaves us with a grave problem. Injecting our code into the target's addressing space. Now this can be done in many ways indeed. We'll just be looking the one I chose. What I'll try to obtain is making the program load a DLL for me. This ofcause isn't something the program is willing to do without force. Fortunately for the moment I'm President Clinton and the security counsil has agreed to bomb the target until it conforms to my ideas. The scene is set at the status breakpoint just before the target is about to start execution. It is fully loaded and ready to go. However we're sitting comfortably with it suspended far far away in our own addressing space. The first thing we got to agree on is how it is we actually want's the target to do. Load OUR dll, find the process address of OUR function, replace the one found at the THunk-VA of the original. We now constuct code that will do just that in deltaoffset so that it can be inserted anywhere. Prior to actually running the program we found a page within the target that allowed execution. Most pages in the target allows execution but we just need one. We now read the page out the Process space of the target into our own and stores it safely. This is done thru another subfunction of INT 2eh which ofcause also overrides pageprotection etc. The API is: kernel32!ReadProcessMemory See Natzguls essay for a more thourough breakdown of this function. Now we write our own code that loads a DLL, finds the address of our function and replaces the Thunk-VA entry of the function with ours. Now were ready to go? No. We're left with the problem that execution should be left otherwise unchanged so that we've written a page somewhere is bad news. So in addition to the code we appended we add an INT 3 which will when executed cause a debug event and once more suspend the target allowing us to restore the page. Unfortunately EIP of the target does not neassesarely point to our page, further we use all the registers and those needs to be restored too. So where do we turn? Windows internal knowledge. Upon creation that is prior to running any actual program code any one process has one and one thread only. Further Windows allows debuggers to fetch the Context of a thread. That is all relevant information about the threads current status. Such a context was originally intended for preemptive multitasking so that when ever the OS suspended execution of the thread to do another the context was saved, the address space swapped and another threads context was restored it's process's address space swapped in place and it was allowed to continiue. One should be aware that while a thread indeed has full context it's partly shared with that of the other threads in the process. E.g. the FPU is shared between threads in a process. Since we only got one thread in our process the terms of thread and process is incidental. I will not get dirty with the exact definitions of thread and process since a breakdown of operating system concepts is beyound the scope of this here text. Iceman (1998) has a brief description. We ofcause now reads the context of our target's single thread, saves it then changes the EIP in it an resets it to point to our page of code in the target processspace. Ofcause our code will now execute till the int 3 we inserted is reached, then it's suspended and control is back with us. We now reset the context of the thread and restore the page we abused for our code. Then we simply let it run. There is one last unfortunate thing about letting it run. If a process was created in Debug mode it stays in debug mode till it's terminated. That means that we need to stay in a loop of WaitForDebugEvent/ContiniueDebugEvent until that time where the process is actually terminated or the program will suspend itself and wait for our instructions. This wasn't too smart MS! Practical notes on the debug approach A last side note should be mentioned here. For reasons of alignment the Context structure should be on an address A so that (A and 3)=0. This is indeed not documented in MS's documentation of GetThreadContext. It is this that left me to believe that there was a bug in Windows NT in a previous edition of this text. Thanks to Quine for this correction. The reason that this alignment is required seems to be one of processing speed as x86'ers does not require this type of alignment. Further finding the ChunkVA of an imported function can easily be done by dumping the PE-file with Matt Pietreks PE-dump or similar. He gives the first chunk for each DLL, if your function isn't the first you add 4 bytes each time you need to move a line down to find our function. The sourcecodes for this can be found at: ******************************************** ------------------------------------------------------------------------ --- The MessageHook Approach I'll skip relatively lightly over the in-depth technical issues of this method. It is simply far beyond this text to go into it. Maybe someday I'll write a book or something :) sorry.. The above method has it's advantages - and disadvantages. It's cumbersome. Indeed in many instances access to foreign addressing spaces can be gained easier. I will now examine one such method. The method was first described in MSJ 1994. I first noticed the potency of this method examing Grudge's crack for SubSpace. My sourcecodes and approach as such bares many resemblances with Grudge's initial work. Most likely you've all encountered Windows Messageing system at one point or another. Breakpoints on "BMSG", HWND command in Winice is indeed breakpoints on messages and list possible recievers of messages. The whole idea behind messages goes back to the fact that we have a multitasking operating system. Several tasks needs to share equipment that can only be used by one at the time. The obvious example is the mouse - the user will have only ONE mouse total, not one for each thread. Another is the keyboard, keyboard input is often ment for only one of the running threads. A total breakdown of the windows messageing and windowing system is far far beyound the scope of this small text. It'll suffice to say that any window made by any thread in any process is controlled thru messages from the Windows operating system. Again we'll exploit that Windows is an overbloated operating system - or well as I would rather put it - a very potent equipped OS. The feature we'll be exploiting here is that of a Hook in the message system. For many reasons Microsoft decieded that even at ring 3 people should be able to intercept messages send to windows. Because they wanted this hook to be usuable for Computer Based Training they decieded that a hook would be no good if it did not have direct access to the addressing space of the process belonging to the thread it captured a message for. So they decieded that a MessageHookHandling procedure should be loaded into any process in which it captured a message. Further developers must've felt generous the day they designed this. They allowed a hook not just to one process - but to all! Let's get a bit more technical on this. The API that installs the hook is: User32!SetWindowsHookExA The first problem about using this API to hook windows messages globally is the way it gain access to the address space of the thread which it intercepted a message to. To get real deep on this issue is again far beyound the scope of this text, but it has to do with how modules is mapped in pages thru out the various memory contexts (Process addressing spaces). The result is that you cannot have the hook within the EXE file that installs the hook - rather you need to have it in a DLL. In other words we start out by loading the DLL in which we have our hook, then find the address of our hook procedure in it and feed this to SetWindowsHookExA. The next problem we encounter is that of designing a messagehandling system. Since a LOT of messages is send out to windows system wide all the time it's important that we design our hook to be relatively fast or we'll be slowing the system. The easist way of doing this is only acting upon messages of a specific type. Choosing type depends on how you wish to time your patch. You can in this way time it to hit on keyboard activity in a window, mouse activity, windows being put to background and so on and so forth. I've choosen the real simple hook type intended for ComputerBasedTraining. This hooks a large number of messages related to windows giving us plenty of things to act on without intercepting everything. Further in the hook procedure I test weather the message send was one that is supposed to create a window. This allows me to patch right after the "main" window of the program is created. Without intercepting too much and even when intercepting I only run a few bytes of my code unless ofcause it happens that the program is creating a window. Obviously I might end up patching more than since this message type can be send many times. Other strategies could be hooking the keyboard, all messages etc. I very much believe that which type of hook and the exact design of your hook-handler is an issue that should be solved in relation to the specific problem you're dealing with. For instance in training hooking the keyboard and only acting on specific keys would be a good idea instead of acting on the window. Mammon/HCU suggest a boolean variable to see if you already applied a patch. This can be a very good idea. Even better would be if you shut down your hook-installing process (program) and the hook along with it after you've patched. You should however be aware that this method has a caveat if your user deciedes to run multiple versions of the program you patched or if you're patching kernel32.dll in memory since this DLL might need to be patched more than once because an unpatched version might later on be mapped into your target's addressing space. Thanks to Mammon/HCU for a beneficial suggestion. The next problem is that we need to hinder that we patch all processes. Again I abuse the concept of modules. By getting the current module filename and compareing it to the filename of the file we desire to patch I can identify weather this message was send to the target or to another program windows. And the last problem is ofcause that we cannot keep messages from the target's windows and expect it to perform like it's supposed to. What we do is that we chain other possible hooks using the neatly provided API: user32!CallNextHookEx One final things is worth noting Exiting the process who "owns" the hook will destroy it - in other words we cannot shut down until we're sure we've patched the program and we cannot shut down if need multiple patches (as patching e.g. kernel32.dll (which is a bad idea anyway) would require. The good thing about it is that we can simply call ExitProcess when we're done and windows will take down the hook for us with no further adue... Pretty clever MS! Since we in the hook-procedure have direct access to the addressing space of the target process we wouldn't need to use WriteProcessMemory, however it's a very good idea to do so. First and foremost WPM as described earlier overrides pageprotection. Second and also important - there is a difference in how pages in a process is handled between Windows 95 and Windows NT. If you patch a program's pages in Win NT (if it's not shared) it'll be copied and then the copy will be patched - thus the patch will not affect other processes utillizing the same module. In windows 95 this is not so. However WriteProcessMemory in Windows 95 has build in this mechanism ensuring that if you use WriteProcessMemory you'll not suffer differences between NT and 95. (This is not true if you patch above the 2g limit - which I btw cannot see why you'd do) Here at the end I'll shortly describe the caveats of this method. It requires a window. Without a window in the target process you can't do didly with this method. However you can use this method to inject a DLL into the address space after the window has disappeared and then patch the IAT to make a API-hook of it like in the Debug-approach section. Sourcecodes is avaible at: ******************************************** ------------------------------------------------------------------------ ------ Litterature MadMax (1998) - Cracking using kernel32??, by MadMax Feb 1998. ****************** Natzgul (1998) - Unknown tittle, by Natzgul Jan 1998. ****************** Iceman (1998) - Tweaking with Windows 95 memory, by Iceman jan 1998 ***************************** Pietrek, Matt - Windows 95 System Programming Secrets, IDG books 1995. MSJ (1995) - Microsoft Systems Journal May 1995, Jeffrey Ritcher. Various sourcecodes by Me :).. all can be found on my page ************************ ------------------------------------------------------------------------ ----- Thanks must go to: Patriarch / PWA, friend, roomate and local expert. Random / Xforce, God of the PE-format Net Walker / Brazil Quine / HCU Acpizer / UCF, nah.. couldn't use what you send me.. but thnx anyways. Grudge / CLS, it's been a pleassure abusing your work :) Mammon / HCU IceMan / HCU United Cracking Force, my personal benefactor. All of which I had many enlightning discussions with. Also I'd like to thank HalVar/HCU WayneKerr/F4CG LordByte/UCF Madmax/HCU G-Rom / Phrozen Crew The Owl - Zen god of WinIce and a master of windows who have thought me a lot. and many others for their encouragements email: ************ ************************ Stone / UCF & F4CG 2nd&mi! -----#3------------------------------------------------- Subject: re: Assembly book To: _m and others No, I mean the right title, and it is registered at Amazon.com as "hard to find". In the book "Mastering Turbo Assembler" Turbo Debugger is briefly mentionned only on a few pages (37-41), where the author (the same!) admits that Turbo Debugger can be used as an assembly teacher, and shows some examples. Curiously, the book is not mentionned at all in his bibliographical list. Another cuoriosity is the book of Michael Abrash, "Zen of Assembly Language", 1990,(also "hard to find" for Amazon.com), recommended by Jeff Duntemann in his book "Assembly Language", 1992, p.372: "Becoming a master takes work and time. Michael Abrash massive 'Zen of Assembly Language' (now out of print but to be republished soon) is a compilation of the "secret" knowledge of a programming master". The book was never republished, and Michael Abrash continues to write books on the other subjects. It remind us also that the author of +ORC tutorials recommended to use a zen approach. Source references may reveal much. For example, when IDA Pro was announced on Fravia pages, I went to the home site of IDA where the author gave (only in Russian) source references, where the book of Cristina Cifuentes "Reverse Compilation Techniques" (1994) was qualified as the best published source. All sources were English. It means that nothing good was published in Russia on the subject. Those who are interested in Russian sources, have to consult two thick books published by Wrox Press (see their Website): "Revolutionary guide to Assembly language" and "Assembly language. Master class" (all authors are from Russia, only in English). Source references of Cifuentes also reveal much: "Techniques for writing reverse compilers or decompilers are presented in this thesis...These techniques have never before been published" (p.V). Further, p.15: "Decompilation is a tool for a computer professional. There are two major areas where decompilation is used: software maintenance and security... It is not the purpose of this thesis to debate the legal implications of decompilation. The topic is not further covered in this thesis". Thanks. AZ111. -----#4------------------------------------------------- Subject: Re: Assembly Books > >>Can anybody tell me, how to get the book of Tom Swan, > >I believe you are referring to "Mastering Turbo Assembler", a book I picked up acopy of this a week ago in a closing bookstore for 25$... it is a nice book, but if you ask me, for anyone who knows basic assembly, one of the best books to buy is "Assembly Language Master Class", by various authors (P. Kalachnin, Yuri Kiselev, Igor Chebotko, Efim Podvoisky, Kiril Malakhov etc) I bought it in the same shop as the other, after Gthorne said some- thing about it. While much of the source is MASM, it treats just about any topic you'd want to know about (except Win programming, but who would want to program Win anywways ;-) I know much of that stuff will be old for really experienced programmers, but for all those that know basic assembly and not much beyond that this book is a treasure chest. Topics include: - a (short) chapter on Disassembly - device drivers - programming the PIC (interrupt controller) - printing/mouse in assembly - DMA programming /ISA interfacing - sound - low-level Disk programming - data compression - VGA/SVGA - EMS/XMS - Pentium Programming - PMODE - Virii/AV - optimizations The chapter on PMODE is probably the best documentation on how to write pmode programs (DPMI servers, Extenders) I've seen, and it helped me a great deal to understand (and put to use) the IDT and GDT and LDT commands in S-ICE.. I recommend this book for anyone who wants to get past the "jnz BadGuy" cracking :-) The book ain't cheap though, you'll have to pay 50$, but it's very well worth it. I don't know, I haven't cracked sh*t since I bought this book, there's too much stuff to fool around with in there :-) I had a question to this mailinglist a couple o' weeks ago where I wondered why the program never called int9 even when it's Keyboard routine was in int9 :-) Now I know :-) (I know, all you old school guy's will say "big deal" :-) When it comes to "mastering Turbo Assembler" I have to say that this book is good if you don't use Macros and conditional assembly yet, but if I had the choice between Master Class and Mastering, I know what to choose :-) ISBN for "Assembly Language Master Class" is 1-874416-34-6 49.95 US &, $69.95 Can and 46.99 UK :-) And you know you made a good progress once you write your own extender :-) Hey, anyone wanna develop a new OS ;->>> (don't take me seriously on this one) HalVar ______________________________________________________ Get Your Private, Free Email at ********************** -----#5------------------------------------------------- Subject: Fravia's Page I just thought I'd share this with you. I was reading through the documentation on a program, XDesk to be exact(I really like it too, so many features!!! Check it out.) anyways.. I thought this was kinda funny, here's the quote: "Actually the "time protection" is not actually intended to stop you from "stealing" this program - any beginner in "reverse engineering" (see fravia's pages, the best site with this kind of stuff !) can get some results in less than five minutes -" So instead of protecting it well, he admits that it's protected pathetically and he expects it to be cracked. hehe... I don't know who the programmer is but that's a person I can respect. ----- [ REKLAMA / ADVERTISEMENT ] ---------------------------------------- Lubisz film?! Wiec na co czekasz? Przylacz sie do FILMWEBU! Pierwszy Polski Serwis Filmowy w Internecie ********************* -------------------------------------------------------------------------- =====End of Issue 187=================================== ======================================================== +HCU Maillist Issue: 188 04/08/1998 -------------------------------------------------------- Send Articles To:......................... ************* Info, Help, Unsubscription, etc:....... **************** Web Repository.........................hcuml.home.ml.org ======================================================== CONTENTS: #1 Subject: gthorne - on tempest ARTICLES: -----#1------------------------------------------------- Subject: gthorne - on tempest Message Body = tempest specs refer to more than cabling i thought the 7x erasure was in that reading, but looking back - it was mentioned in the same article where i first read about tempest - it ws on government security in general tempest itself requires that not only are there high grade cables, but the rooms must be armored... ie: lead lined to prevent EM that is how they solve it recently i read about how much government surplus military mechandise was being marked as 'destroyed' or 'inoperable' and yet was mis-marked everything from tanks to automatic weapons to guided missile systems are being sold at ridculously cheap costs on the open market - so their paranoia in creating a tempest spec to keep people from using scanners to pick up your keypresses is justified... especially when the rest of the world has access to USA's own high tech equipment effectively - reading more and more about government oversights, the more scary it becomes +gthorne =====End of Issue 188=================================== ======================================================== +HCU Maillist Issue: 189 04/09/1998 -------------------------------------------------------- Send Articles To:......................... ************* Info, Help, Unsubscription, etc:....... **************** Web Repository.........................hcuml.home.ml.org ======================================================== CONTENTS: #1 Subject: Tempest #2 Subject: Cookies and protection schemes ARTICLES: -----#1------------------------------------------------- Subject: Tempest Equipment conforming to the standards detailed in NACSIM 5100A are called 'Tempest Certified'. Unfortunately the document has been classified by the NSA so we don't actually know what the standards are. In fact, they seem to have classified everything to do with the subject. Professor Wim van Eck wrote a paper on the subject of capturing e/m emissions and estimated that they could be picked up from around 1km away. The receivers are sometimes called van Eck devices. (BTW, the NSA classified his paper :) It's hard to guess how effectively you can protect yourself from a 'Tempest' attack. I think I'll build a van Eck device later this summer and test it out. I believe that it would be impossible to completely shield yourself (at least on the budget of mere mortals!) but perhaps it would be possible to protect yourself from the 'hobbyists' because the scariest thing is that these devices are not difficult to build. Even a lead lined room wouldn't be much good.. your computer's attached to the telephone line which not only is a perfect antenna, but probably leads all over your house! I'm not convinced that a sealed, windowless, lead lined room would be sufficient anyway - I think you would probably need something like a faraday cage. ~~ Ghiribizzo -----#2------------------------------------------------- Subject: Cookies and protection schemes Hi all! Take a look at ************************* here you can download time-limited program (jackpot, etc...) with a unusual protection scheme... I SUPPOSE! This program use, in fact, the cookies and Temporary Internet Files folders and win.ini (in the download page they say: 'ATTENZIONE: Il download richiede Internet Explorer.') Thanks. n0m0re ______________________________________________________ Get Your Private, Free Email at ********************** =====End of Issue 189=================================== ======================================================== +HCU Maillist Issue: 190 04/11/1998 -------------------------------------------------------- Send Articles To:......................... ************* Info, Help, Unsubscription, etc:....... **************** Web Repository.........................hcuml.home.ml.org ======================================================== CONTENTS: #1 Subject: Free Call #2 Subject: van Eck device #3 Subject: Security, Tempest, etc. #4 Subject: help... ARTICLES: -----#1------------------------------------------------- Subject: Free Call Has anyone hints to phone for free on Net to people not on Net? Like Net2phone? Ceban ______________________________________________________ Get Your Private, Free Email at ********************** -----#2------------------------------------------------- Subject: van Eck device Hi Ghiribizzo! You wrote: >It's hard to guess how effectively you can protect yourself from a >'Tempest' attack. I think I'll build a van Eck device later this summer and >test it out. I believe that it would be impossible to completely shield >yourself (at least on the budget of mere mortals!) but perhaps it would be >possible to protect yourself from the 'hobbyists' because the scariest >thing is that these devices are not difficult to build. Could you please describe briefly (or in detail if you have time :) how does this device work? I wonder how they can pick up the radiation of a particular computer from an office building with many identical pc-s. Thanks Zer0+ -----#3------------------------------------------------- Subject: Security, Tempest, etc. Writing o pubcly on the security issues may be considered by some readers as a sure sign of ignorance. It is not true: one can longly discuss generals issues without revealing his personal counter-measures and his personal extent of knowledge and without misleading information. Many books have been published on the issue, one of them: John Vacca, "Internet Security", Copiright 1996 IDG Books Worldwide, Inc., English, German and French versions, more than 900 pages. One can think that a classified information is much better. It is not always true. For example, Tempest topic. It is for a military personnel, which live in another environment: they are disconnected from a o pubc network, have other tools and hardware, free at their disposal. Those who are interested in E/M computer radiations, should consult the "Spycatcher", a bestseller forbidden in GB: it is related there how computer radiations from a French Embassy were captured by spies. Those of us who are concerned with the issue may try to pollute the E/M environement around the computer: it would be much cheaper. If one plans an intrusion, he will search for a weakest chainlet in the ring-mail protection. And the weakest ring in our case, it seems to be phone lines, which we alone cannot secure. The ideal would be a direct sattelite access through a narrow beam. The first data to acquire for a planned attack would be a phone number of your computer. It is relatively easy: one has only to consult the Phone Directory of your region, your name should be there. Then your computer should be on the same line, or very near. Many give willingly (or are opubged to give) their phone number at certains Web sites. If one fails to monitor your computer, he may try to distroy it logically (by virii) or physically (virii attacking the hardware by triggering certains devices, electrical discharges, vandalism, robbery). Badly set security often gives contrary results: for example, encrypting certain files or passages will guide the intruder directly to the sensitive data, or reveal the persons with whom you exchange that data. Happy nice Easter holydays for everybody. The awaken Nature can teach us a lot. The defensive approach is always cheaper and easier, than offensive. AZ111. -----#4------------------------------------------------- Subject: help... yo wuddup... im kind of a newbie here so could someone clear something up for me?? whats the difference between WinIce and SoftIce...??? right now I have SoftIce and the icon to the Loader prg is a little "A" looking thing... so whats WinIce...?? I was reading this one tutorial in PDF form and it told me to change a couple of things in the WinIce.dat in the WinIce dir... i found WinIce.dat in my SIW95 folder... isnt that the SoftIce folder?? I thought its supposed to be in the WinIce folder.... im kinda confused... A Totally Helpless Newbie, TecH_bOi There should be no JUNO tagg-line after this line... if there is text that says something about JUNO then just dont pay attention to it... =====End of Issue 190===================================