Re: T13 Secure Erase - C / C++ / MFC Discussion Boards

RomTibi5-Apr-13 11:46

5-Apr-13 11:46

I want to implement T13 ATA Secure Erase and can not find any documentation. Is something available?
I found this http://cmrr.ucsd.edu/people/Hughes/SecureErase.shtml[^]

36. When you surround an army, leave an outlet free.
...
Do not press a desperate foe too hard.

SUN-TZU - Art of War

Re: T13 Secure Erase

dusty_dex5-Apr-13 21:08

dusty_dex

5-Apr-13 21:08

There are other factors to consider besides secure erasure.

Like data remanance, correctly implemented PC BIOS (ie. it hasn't been compromised), PCI cards with onboard BIOS etc. Plus there's the thorny issue of SSD data remanance.

If at all possible the HDD should be encrypted, but not so good with SSD.

harddisk_ata_security_v1.1-1.pdf

"It's true that hard work never killed anyone. But I figure, why take the chance." - Ronald Reagan

That's what machines are for.

Got a problem?
Sleep on it.

Re: T13 Secure Erase

RomTibi6-Apr-13 2:18

RomTibi

6-Apr-13 2:18

Thanks for answering to my problem, but I have a simple task and I can`t find documentation on T13 Secure Erase Cry | :((

36. When you surround an army, leave an outlet free.
...
Do not press a desperate foe too hard.

SUN-TZU - Art of War

Re: T13 Secure Erase

dusty_dex6-Apr-13 7:53

dusty_dex

6-Apr-13 7:53

I had a look at the t13.org website and they allow you download documents if you register and login.

Smile | :)

"It's true that hard work never killed anyone. But I figure, why take the chance." - Ronald Reagan

That's what machines are for.

Got a problem?
Sleep on it.

Re: T13 Secure Erase

RomTibi6-Apr-13 8:39

RomTibi

6-Apr-13 8:39

Thanks again. I searched the site before. Actually I need something like an API or SDK. Frown | :(

VII. 36. When you surround an army, leave an outlet free. Do not press a desperate foe too hard.
SUN-TZU - Art of War

Re: T13 Secure Erase

Randor 6-Apr-13 17:56

Randor

6-Apr-13 17:56

Hi,

Everything you need is in the ATA specifications. I believe the first ATA spec that contained the secure erase command was in ATA3 from 1997. However not all hard drive manufacturers implemented this until around 2001.
http://www.stanford.edu/~ouster/cgi-bin/cs140-winter13/pintos/specs/ata-3-std.pdf[^]

The latest version is ATA-8:
http://www.t13.org/documents/UploadedDocuments/docs2006/D1699r2b-ATA8-ACS_CB.pdf[^]

If I remember correctly you will need to set the ATA password first with command 0xF1. You will then need to issue ATA command 0xF3 followed by an 0xF4.

If you are doing this in Microsoft Windows... you will need to implement this as a device driver. You cannot issue ATA commands from a usermode application.

Good Luck,
-David Delaune

Re: T13 Secure Erase

RomTibi7-Apr-13 6:34

RomTibi

7-Apr-13 6:34

Thanks a lot Smile | :)

VII. 36. When you surround an army, leave an outlet free. Do not press a desperate foe too hard.
SUN-TZU - Art of War

Re: T13 Secure Erase

Joe Marley9-Apr-13 11:32

Joe Marley

9-Apr-13 11:32

David's pointing you to the spec is an excellent answer.

A few things I will add to the mix:

* You will need multiple commands ( SECURITY ERASE PREPARE, SECURITY ERASE UNIT, and possibly other SECURITY commands ) from the spec in order to accomplish a secure erase.

* Sending (single-sector) ATA passthru commands from uesr mode applications is possible on Windows (XP SP2 and newer, IIRC), assuming you have Admin privileges on the system. You will need do some Googling on IOCTL_ATA_PASSTHRU_DIRECT in order to find relevant information.

* That being said, you will still be at the mercy of the system BIOS and possibly the O/S. Once a SECURITY FREEZE LOCK is sent to the drive, it is *generally* difficult or impossible to send SECURITY ERASE to the drive. Some motherboard BIOSs send the SECURITY FREEZE LOCK prior to start of boot just to ensure a drive is not accidentally or maliciously erased.

All of this is from my memory, which is several years old at this point.

Screen Lock for MFC App

Donguy19765-Apr-13 11:31

Donguy1976

5-Apr-13 11:31

Hello All,

I have a MFC app thats being developed in VS 6.0

If the app is idle for more than 5 mins it should lock automatically.

i.e., the next time when user tries to click anywhere on app, it should ask for user name and password.

Is there any good examples for that?

The closest example i can think of is the screen saver lock in Windows operating system.

Any sample code will help.

Thanks in advance.

Re: Screen Lock for MFC App

André Kraak5-Apr-13 12:29

André Kraak

5-Apr-13 12:29

Have a look at this article HOWTO track a user's idle time[^]; it seems to have a good implementation on how to detect the idle time.
When the idle time (five minutes) has been reached you could show a modal dialog that requires the user to specify his/her user name and password.

0100000101101110011001000111001011101001

Re: Screen Lock for MFC App

Randor 6-Apr-13 18:18

Randor

6-Apr-13 18:18

Hi,

I recommend that you have a look at the GetLastInputInfo function[^].

Best Wishes,
-David Delaune

PlaySound method doesn't function in a Win7 Srvany Service

rhfritz15-Apr-13 5:48

rhfritz1

5-Apr-13 5:48

I have an application that can also run as a service via srvany. It performs a monitoring task and uses the PlaySound method defined in mmsystem.h to play a .wav notification on certain events. It runs fine under XP as an app or as a service.

Under Win7, the app runs fine. But when running as a service under Win7, I get no sound. The "allow service to interact with desktop" option is available but ignored under Win7 as part of Session 0 isolation. I expect this is somehow related.

I'm looking for verification or alternate approaches.

Thanks.

modified 5-Apr-13 13:28pm.

Re: PlaySound method doesn't function in a Win7 Srvany Service

MicroVirus10-Apr-13 0:23

MicroVirus

10-Apr-13 0:23

You are most likely right in your conclusion. I think the session 0 isolation prevents such interactions.
A possible work-around is to have your Service start or interact with a non-service component that runs in the user session.

OnFileOpen crashing

_Flaviu4-Apr-13 22:31

_Flaviu

4-Apr-13 22:31

I have weird bug: in a MDI aplication, if I mapped OnFileOpen in follow way:

C++

ON_COMMAND(ID_FILE_OPEN, OnFileOpen)

after the document file has opened, the application crashes with follow message:

C++

(KERNELBASE.DLL): 0xC0000005: Access Violation.

but only in Release mode ... in Debug mode, everything is going well ...
if I mapped OnFileOpen in follow way:

C++

ON_COMMAND(ID_FILE_OPEN, CWinApp::OnFileOpen)

again, everything is going well ... did you meet with this behaviour ? Perhaps you give some hint ... Thank you.

Re: OnFileOpen crashing

CPallini4-Apr-13 22:40

CPallini

4-Apr-13 22:40

In a Debug build the compiler performs additional tasks, for instance it zeroes variables you haven't initialized (e.g. WinAPI structs) (in Release build the unitialized data contains garbage).
Have a look at the following CodeProject article: "Surviving the Release Version"[^].

Veni, vidi, vici.

Re: OnFileOpen crashing

Jochen Arndt4-Apr-13 22:42

Jochen Arndt

4-Apr-13 22:42

Check your CMyApp::OnFileOpen() code and the functions that are called from there. Comment all lines in that function except the base class CWinApp::OnFileOpen() call and uncomment step by step until the violation occurs. Then you should know which part of your code is responsible.

Re: OnFileOpen crashing

_Flaviu4-Apr-13 23:07

_Flaviu

4-Apr-13 23:07

Inside of CMyApp::OnFileOpen I didn't call CWinApp:OnFileOpen .. here is the buggy code:

C++

void CMyApp::OnFileOpen(void)
{
	CFileDialog dlgFile(TRUE);
	dlgFile.DoModal();
	return;
}

and in release mode, the application crashes ...

Re: OnFileOpen crashing

_Flaviu4-Apr-13 23:26

_Flaviu

4-Apr-13 23:26

Even if I used:

C++

void CMyApp::OnFileOpen(void)
{
	CFileDialog dlgFile(TRUE);
	return;
}

and the application is crashing down ...

Re: OnFileOpen crashing

Jochen Arndt4-Apr-13 23:35

Jochen Arndt

4-Apr-13 23:35

Crashes it in this function or later?

If you did not call CWinApp::OnFileOpen(), no document is created. So the reason for the crash is probably somewhere in your document creation. Did you call OnFileNew() or use ProcessShellCommands() to create a document?

Re: OnFileOpen crashing

_Flaviu4-Apr-13 23:46

_Flaviu

4-Apr-13 23:46

No, I didn't call CWinApp::OnFileOpen, but I call OpenDocumentFile(...), something like that:

C++

void CMyApp::OnFileOpen(void)
{
	CFileDialog dlg(TRUE);
	if(IDOK == dlg.DoModal())
	{
		POSITION pos = dlg.GetStartPosition();
		while(pos)OpenDocumentFile(dlg.GetNextPathName(pos));
	}
	// the document is loaded, I can see the bitmap in child frame ...
	AfxMessageBox("By here, everything it's OK.");
}

after all, I think that the problem it's in another place ... I really don't know ...

And this is weird, because if I open the same file from MRU, everything is OK ...

modified 5-Apr-13 5:54am.

Re: OnFileOpen crashing

Jochen Arndt5-Apr-13 0:12

Jochen Arndt

5-Apr-13 0:12

It's difficult to find such errors in release versions. Using a message box is a good idea to check where the violation occurs. Because it occurs when not calling OpenDocumentFile(), I assumed that it is somewhere in the document handling (e.g. trying to access non-existing documents).

But when it is OK using ProcessShellCommands() (MRU) D'Oh! | :doh:

At the moment I have only two ideas:

Call OpenDocumentFile() with a fixed file name to see what happens (no other calls from within OnFileOpen()).
Perform a complete rebuild if you have changed something in your project.

Re: OnFileOpen crashing

_Flaviu5-Apr-13 0:27

_Flaviu

5-Apr-13 0:27

This is became strange: if I call only:

C++

OpenDocumentFile(_T("D:\\Flaviu\\SampleImages5\\Test.xxx"));

, everything is OK, but when I go through normal way:

C++

CString strFile;
if (dlgFile.DoModal()==IDOK)
{
    pos=dlgFile.GetStartPosition();
    while (pos!=NULL)
    {
        strFile=dlgFile.GetNextPathName(pos);
        AfxMessageBox(strFile);
        OpenDocumentFile(strFile);
    }
}

is crashing down ... in Release mode only ...
I have to digg in ...

Re: OnFileOpen crashing

Jochen Arndt5-Apr-13 0:31

Jochen Arndt

5-Apr-13 0:31

So the problematic code is at least isolated even when it looks OK. As next step you may assign the fixed file name to strFile ignoring the selection from the dialog.

Re: OnFileOpen crashing

_Flaviu5-Apr-13 0:32

_Flaviu

5-Apr-13 0:32

Another trial:

C++

CString strFile;
if (dlgFile.DoModal()==IDOK)
{
    pos=dlgFile.GetStartPosition();
    while (pos!=NULL)
    {
        strFile=dlgFile.GetNextPathName(pos);
        AfxMessageBox(strFile);
        OpenDocumentFile(strFile);
    }
}

AfxMessageBox("Second chance");
OpenDocumentFile(_T("D:\\Flaviu\\SampleImages5\\Test.xxx"));
AfxMessageBox("Final ...");

the crashes is occur only after the "final" message box ...

Re: OnFileOpen crashing

SoMad5-Apr-13 0:51

SoMad

5-Apr-13 0:51

Did you try doing a Rebuild All like Jochen suggested?

Soren Madsen

"When you don't know what you're doing it's best to do it quickly" - Jase #DuckDynasty

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.