This is sort of a long story:

I have been tracing some protected application that stores its state of non-registered (01) or registered (00) in a global long flag variable lets say [006BB976].
I tried to find the code that WRITES the registered state to that location, so I placed a BPMD 006BB976 W in softice while I was at the code entry point.
SoftIce did not break. I examined this area of the memory and it is initiallized to a 01 state. I manually changed to 00 and let softice run again: It did not break and somehow, the flag was set to 01: Someone had accessed that piece of memory, set the flag and escaped Sice hardware breakpoint! How??

I changed the break point to BPMD 006BB976 RW and found that early in the course of the program Sice breaks See picture:

Softice is deep into the NTOSKRNL.DLL and actually the call stack goes through NTIce itself (!?)
If I trace back into the appication itself it is writing into the adjacent dword to my flag.

The application protection did not look very sophisticated to me. I tried the same approach, same breakpoint in Olly and got





Right where it belongs, catching the app setting the badboy flag

What is the deal? Why SoftIce does not catch the write to memory BP?? What are these ReadAheadGRanularity APIs and why Sice gets sidetracked into tracing the kernel and tracing itself when I try to detect the access to this innocent variable?? Olly has no problem.

Daam you naides, you know full well I can't resist a Softice mystery!

Ramblings to follow,

What'd you use to get the Sice screenshot btw?
..Strategically placed "bullet holes" are interesting.., damn mods anyway.

The stack trace is weird, esp. the duplicate RetEIP to 804D7A5B. What is there in your system? On my XP this is actually in a blank section of the PE Header portion of ntoskrnl (MZ+A5B).

The RetEIP of F82BA3B4 is actually an Ntice function, you should be able to confirm this.
If you type 'DRIVER ntice' to get the Start address,
then MZ(Sice) + 953B4 should give the offset listed
NTice!.text+95034

Hopefully you'll find this proc (for DS3.1)



The function AccessBPTable I name because it parses through the TDJF Breakpoint Table I defined in the threads:
http://woodmann.net/forum/showthread.php?t=6464&
http://woodmann.net/forum/showthread.php?t=6930&

The CallCptHook_1 you can trace into and see it calls a cpthook.sys function. What the cpthook call does is to check that value of 6 and if SOMETHING, return a STATUS_INVALID_HANDLE value (0C0000008h). I don't know exactly what that SOMETHING is.

Normally I would have *guessed* that the push 6 represented the breakpoint type, because of what the code is associated with. But, that value defines BMSG = 06h, not BPM. However, cpthook perform a small conversion on the value,

// eax and ecx refer to stack parameters sent by Ntice
imul eax, 2Ch // eax = 6
add eax, [ecx+18h] // ecx = ?
so it still might be relevant to a BPM



Notice that the BP table contains the Module_Name, which is actually a reference to the proper breakpoint context. This might be relevant since the STATUS_INVALID_HANDLE can be returned from cpthook.


As to what's 'causing' all this...

I know you are fully aware of the importance of context, esp. with BPM breakpoints. They must be set in the process context, preferably at program start, and be executed immediately. Once you break *out* of context, they are more than likely not going to "stick". And they do not usually work on another run of the same process, it's best to clear BPM bp's entirely and re-type them in each time.


Taking all this into account, my only guess as to the real reason the BPM won't stick is, perhaps the switch to MFC42 is causing the thread to jump 'out' of context, and the bp fails.

The fact that Ntice is in the stack trace at all is probably because it's monitoring for your BPM to be hit. Since it may be out of context when it does hit, cpthook returns that error message after checking the module name.

You might check other BPMs between MFC42 calls and see if they stick or not. And then BPMs that don't encounter MFC42 and are sure to remain in context. If mfc42 is a problem, does this bode well for the VB dlls and others?

Tried SET BREAKINSHAREDMODS ON?

Cheers,
Kayaker

Memory write breakpoints in SICE have always been extremely shaky for me, even since the good old days before the context problem was even born. I even completely stopped using this feature in SICE because it was so unreliable. :/

If I may veer off topic for a moment, considering that SoftICE is dying such a painful death, what's good in the ring0 debugger scene these days? Does anything compare to SoftICE's performance on Win9x?

Answers:

To Kayaker: Actually, I was counting on you for some insight is my Sice misadventures. Who else has the knowledge, the kindness and the affability to do something like that?
I have not come up to write with a necessarily researched answer to your answer because I have not been sober for the necessary length of time these days. I will do it soon . . . Next year. . . It is my resolution. Cheers, and happy 2006 once again

To Admiral:
No thread hijacking resentment here, I did it to you before. . .

Think about "trusted computing" in which the CPU is part (bought by) of the, and works in collusion with, the protectionists and the copyright establishment. What future or what use would a Ring 0 (or ring sqrt(-1) for that matter) have if the computer inner workings and the code has been effectively taken from us, the mere mortals, by the powers to be?

I'm not convinced that trusted computing is anything worth worrying about.

Manufacturers of such processors will have a tough time selling their products when the competition is still producing open core chips: The malware argument alone is enough to scare most home-users away, and the debugging limitations will bother developers. If you then consider that there is little application for trusted computing in server situations, there's really not much of a market left.

So let's suppose that some movement passes preventing the manufacturers from making/distributing anything that's open-core. Then the standards will change and the large community working at a level below assembly language will need to know the architecture of their processor inside-out (as they do now), meaning the speifications will have to be well-documented. At this point, it's only a matter of time before we can emulate the processors easily and efficiently. This brings us back to square one (or maybe square two).

We could go on to contrive a situation where trusted computing becomes widespread and universal, but the notion doesn't strike me as being realistically profitable at all.

The again, who knows? Maybe I'll be eating my hat in ten years' time.
Admiral

It is definitely something to worry about. Manufacturers of such processors will include Intel and AMD starting in 2006. Manufacturers who do NOT start using DRM in their chips are going to be left out in the cold. Already we are seeing monitors and TVs with HDMI interfaces that will not work with protected content unless end-to-end encryption is enabled. Microsoft and Hollywood are leading the charge and big names like Intel, AMD, HP, IBM and Sony are 100% on board with all the new DRM tech. There has been a lot of ballyhoo about evil DRM for a few years now, but 2006 looks to be the year it emerges from the shadows and onto the desktops of new PC buyers.

That movement is called the US Government. There are new laws being introduced every few months that seek to outlaw any analog-to-digital electronic product that does not enforce the "rights" of the entertainment industry. The software industry will follow in short order. Some of the standards are not open. You can't look at them without paying a licensing fee or signing a non-disclosure agreement. Satellite TV pirates have been shut down over the last few years and they NEVER cracked the digital encryption of the signal. They worked around it, but they never successfully cracked it. Same thing now with XM and Sirius satellite radio. Sony's Playstation 2 has been out for 5 years now and nobody has successfully cracked their "magicgate" protection. Once there are black box chips that hold encryption information on every PC, like Trusted Computing requires, there will be little left to crack.
Quite the contrary, it's seen as the ONLY real route to profitability. Once software appears that takes advantage of Trusted Computing features - and it will finally happen in 2006 - there will be no profit allowed unless you play by their rules.

Better lay in a good supply of salt & pepper because it will all start to happen next year. 10 years? Hah! Less than 10 months. Of course you can stick with your non-TC and non-DRM hardware for awhile but once every machine comes with this stuff built-in we really won't have much of a choice. TC, from what I've read, can be turned off. But there will be very little software that will run with all its capabilities enabled if you turn it off. It's all real and it's all very close to happening.

Rummy,

You sound as convinced that the trusted comupting revoultion will occur as I am unconvinced. But like I say, it's very much up in the air right now. Your arguments seem very plausible and logical, but you rely heavily on the fact that processor manufacturers will embrace the idea of trusted computing with total confidence. I'm sceptical that mainstream manufacturers will be so happy to up sticks and reinvent their specs just because the anti-piracy organisations tell them to.

You successfully sidestepped the idea that malware authors could take advantage of such technology (with severe consequences) and anybody who claims otherwise is ignoring years upon years of evidence on the contrary. AMD and Intel will obviously bear this in mind and they know that their decisions will define the future of computing. I can't see anybody taking any unnecessary risks (certainly where their professional reputation is involved) so as I said before, unless there is some pressure to do otherwise, if I were AMD or Intel I'd happily continue making x86 processors and prey to the highest gods that trusted computing never takes off.

Edit: You mention the US goverment playing a part in the situation. They may well be doing so, but although all the main CPU producers of today ultimately report to them, there is no law saying that all computer manufacturers must do the same. If things go as you say, there will be nothing but good reason for the Chinese (for example) developers to take full advantage of the situation. I'm no economist and I don't know how successful such a movement would be, but I know that I'd be a customer of theirs: I'd rather migrate to an unknown manufacturer than compromise the security of my own computer.

Regards
Admiral

If trusted computing does become commonplace, I believe we'll be seeing more reversing of the hardware than the software. It's worth remembering that all of these are the creations of humans, and thus can be destroyed by humans. We are all equal in this respect.

My prediction is that in the future, there will be two distinct sides, one composed of the TC supporters including the major software and hardware companies, and the other composed of those who despise TC, e.g. us Reversers, Open-Source supporters, and the hardware companies that don't want to implement TC.

I do not think such feature will come out so easily.Check 2A, 3-157 of intel's manual.
Much time ago, Intel tried to intruduce serial numbering onto the processor, and they got flamed so high by the market, customers etc, that they turned to sell those procesors to m$ xbox. Also, they needed more than 20 years to get back to the VAT idea on micro's.
Unless Intel and AMD claimed *together* to get out with such feature on their processor enabled by default, Intell will never risk their safe 80% share for making software producers happy. Nor AMD will risk his 20%. And if Intel does, is likely AMD will not. And someone learnt quite well p3 lesson, enough to risk not so easily, i think (enough as the lesson of selling iapx386+ compatibility to amd, cyrix, ti...)
Regards,
Maximus

Admiral,
Thank you for your considerate reply. It's nice to be able to disagree without getting into a shouting match or flame war

For many years I believed as you do now. All the nasty DRM and TC was in the future. Manufacturers would never go along with it. US laws don't apply outside the US. All those things were true and to some extent still are. I've been seeing a lot of stories lately that lead me to believe that what used to be in the future is about to come to pass.

In the US there are things like the "Anaolog Hole" legislation (http://arstechnica.com/news.ars/post/20051218-5797.html) [http://arstechnica.com/news.ars/post/20051218-5797.html] being proposed all the time. It's Hollywood's dream come true. No electronic device could be sold in the US without protection from unauthorized copying of digital material. Laws like this have been shot down in the past but it's only a matter of time before one of them passes. Manufacturers already cannot sell DVD players in the US unless they comply with the CSS (content scrambling system).

The Blu-Ray disc association said in August they will embrace watermarking, programmable cryptography and self-destruct code (http://www.tgdaily.com/2005/08/10/blu/index.html) [http://www.tgdaily.com/2005/08/10/blu/index.html] in their standards. Blu-Ray discs and players should start appearing for sale next year. Microsoft is including Output Protection Management (http://www.engadget.com/2005/07/14/the-clicker-microsofts-opm-for-the-masses/) [http://www.engadget.com/2005/07/14/the-clicker-microsofts-opm-for-the-masses/] in Vista scheduled for release late in 2006. Intel is already shipping Pentium D processors with DRM (http://www.computerworld.com.au/?id=580672002) [http://www.computerworld.com.au/?id=580672002] chips and they refuse to discuss any of the details. Yes, the serial number fiasco a few years ago caused Intel to back down but they're back with a vengeance. Some people think Apple's switch to Intel processors was because of Trusted Computing factors. (http://www.eweek.com/article2/0,1895,1828859,00.asp) [http://www.eweek.com/article2/0,1895,1828859,00.asp] All major PC manufacturers are starting to put DRM and TC electronics in their PCs. (http://news.com.com/Hardware+security+sneaks+into+PCs/2100-7355_3-5619035.html?tag=cd.lede) [http://news.com.com/Hardware+security+sneaks+into+PCs/2100-7355_3-5619035.html?tag=cd.lede] Even the PC Bios is getting a makeover to support DRM and TC. (http://deviceforge.com/news/NS6888038345.html) [http://deviceforge.com/news/NS6888038345.html]

Reversing the electronics is an interesting area. Costs a lot more than a PC and a handful of software (Olly, SICE, IDA) though! I will just note that the electronics that protected satellite TV have never been successfully reversed, nor have the hardware protections in the Playstation 2 and it has been out for 5 years.

I could be very wrong. I'm only human after all. And now that I review the stories I linked it seems as though it might be 2007 before all these things become commonplace. When you say "in ten years", let's just say that I said that 10 years ago (!) and we're a heck of a lot closer today.

Have a happy new year!

edit: what a pain it is to not be able to embed proper links, but I understand the reason.

Rummy, when you say that the "hardware protections in the Playstation 2" haven't been reversed/cracked, exactly what do you mean?

Of course it has been reversed (and cracked), that's how you start when creating mod-chips (which are effectively the hardware equivalent of crack patches)!?

Yes, but please take note: Once again I edited a post to get rid of the ugly and UNNECESSARY hxxp:// tags that people keep putting in. I wish this trend would stop.

We have already modified the boards script to deal with direct links.

If you leave links with the normal http:// tags, it makes the link easy to copy/paste, and in Opera at least you can select the link and choose Go To URL.

I understand you were trying to create embedded URLs, which aren't supported, but again, the hxxp:// is totally unnecessary.

Once again, please and thanks,
http:// = GOOD
hxxp:// = BAD

Kayaker

Kayaker,
Thanks for the info on the links. I did try to embed the links and they showed up underlined but un-clickable when I submitted the message, so I added in the hxxp thingies. Now I know.

dELTA,
Modchips for the PS2 are a kludge IMO. A real crack would let you boot a custom DVD without one, and also let you use 3rd party memory cards without booting a special disc first. Outside of the licensed memory cards only the datel MAX ones appear in the browser without any special tricks. datel has obviously cracked the magicgate encryption but they're not saying how they did it A "pure" crack like that would let you put custom firmware on the PS2 to bypass all the protections they have. I don't think modchips are a real crack; they're more like workarounds. I guess you could say it's a crack, depending on how you look at it.

Getting back to the original topic... of the strange behavior of the memory breakpoints... I was reading through the Intel manuals when I found this:
There you go. The address you mentioned was obviously not dord-aligned, so the breakpoint behaved unpredictably!

With regards to reversing of the hardware itself, I think we may see more of that in the future. Just don't worry, since anything that humans create, humans can destroy...

Good point. I hadn't noticed the original bp was specified as BPMD. I always use BPM by default which translates to BPMB. That might certainly have been the problem.

Kayaker, have you checked what the referer field of the HTTP request looks like when doing this in Opera? If it uses the page where the link was taken from in the referer field, what you're really saying is rather that we need to modify our vBulletin patch to always enforce hxxp, since otherwise those smartass Opera users can circumvent the entire purpose of that patch to begin with.


Rummy, well rather, modchips are the hardware equivalence of a software crack patch, while what you're talking about is the hardware equivalent of a serial/keygen. And well, as we all know it is quite easy to create a protection that's unkeygennable as long as no additional modifications to the protection are allowed, so it's not really much special with this hardware protection. For this discussion of hardware protections vs software protections to be "fair", you must consider modchips as equal "clean cracks" as software patches, although of course more money consuming and harder to mass distribute than its software equivalence, but that's an advantage/disadvantage that hardware will always have over software (until we invent hardware replicators anyway ).

And also, you said that the PS2 protection had never been "reversed", and this is at least in all ways wrong. Just because you have reversed a protection it doesn't mean you can crack it (this is a property of good protections, compared to security-by-obscurity ones), but even with an ugly crack patch solution you must always have reversed the protection first, to some degree, or otherwise you wouldn't know how to patch it.

Actually, I was counting on it
Sorry I delay answering your posting, but real life got in the way. You all put a lot of sincere effort in your answers and I needed to research my post up to your level




SoftIce and the Debugee are running in a VMWare window. I used CorelDraw (I guess referring to an app here is OK Right??) to capture the bitmap from the Windows Display and to place the bullet holes in the identification areas.
By the way, the weirdness I described happens if I debug the application inside a virtual machine or directly form the host OS and CPU. (I thought for a while that this was a VM idiosyncrasy).

I followed LLXX suggestion and placed a bpm W instead of a BPMD. The BP now breaks where it is supposed to, while the flag is being written by the app at the same area where Olly showed. The flag size is indeed 32 bit dword, that is why I placed a BPMD, but now I know better.

However, when I place a BPM xxxxxxxxxx RW I still break deep into ntoskrnl and NTIce

.

My system is XP SP2 and I am running DS 3.2. At 804D7A5B I find the code of kei386EoiHelper function of ntoskrnl module.


Yes: And it is the same function you found. If I keep tracing, it goes through a NTice interrupt handler, which may explain the weird double return address in the call stack.


It is handling the BPM read during the very early stages of the program loading. The BP is pointing to .data section of the original module that is being copied by ntoskrnl to an alternative location. The Physical destination address and the virtual source address appear to map to the same area of the memory????


In summary, the inappropriate use of a BPMD in Sice sent me on a wild goose chase.
I had the feeling that the protection appeared way too primitive to deal with deep kernel Ring0 stuff, but it was a false alarm.

Thank you for you help, as usual

Thanks for the reply back naides. Isn't it nice when theory supports the observed results?