[Alg] Welke tools heb jij gemaakt? - deel III

quote:

AtleX schreef op dinsdag 09 januari 2007 @ 12:06:
Na de vorige versie van HHV2 nu weer een update, een beta release ditmaal met de volgende verbetering:

[list]

• De verstuurde headers en ontvangen cookies zijn nu ook zichtbaar

.../knip

soulrider wijzigde dit bericht 12-01-2007 00:24 (35%)
Reden: feedback

quote:

soulrider schreef op dinsdag 09 januari 2007 @ 12:33:
[...]


wel handig om ev. header-injectie en dergelijken uit te testen op eigen servers

Of zijn de verstuurde headers en cookies (nog) niet manipuleerbaar ?

quote:

bij mij geeft ie trouwens een error zodra ik het rechtse paneel wil open doen:
euhm onderste pijl is daarvoor precies - fout treedt op als ik op de bovenste pijl naar recht klik zonder iets te hebben ingevuld - mss nog effe opvangen met schoon foutmeldingske ipv crash
// nog niet 'dummy proof' dus
wat info: http://www.soulrider.be/tweak/error.txt (error-raportje)

wackmaniac wijzigde dit bericht 12-01-2007 22:42 (4%)

quote:

wackmaniac schreef op vrijdag 12 januari 2007 @ 22:41:
Na 5 portable apps op mijn USB-stick te hebben getrapt werd ik knettergek van het telkens navigeren door de verschillende mappen. En omdat ik de pstart applicatie van PortableApps.com op eens of andere manier niet fijn vond werken heb ik zelf een versie gemaakt: PortableStarter!
Screen:

[afbeelding]

Hij haalt de applicaties uit een xml bestand, waar ik nog geen editor voor heb gemaakt :-), en haalt het bijbehorende icoontje uit de executable. Het nestelt zich in de systray en vanuit daar kan je de applicaties starten.
Programmaatje is geschreven en C# mbv .Net 2.0 framework. Kritiek, vooral opbouwende, is welkom en geinteresseerden in de source kunnen een PM sturen.

download

quote:

Cypher87 schreef op zaterdag 13 januari 2007 @ 01:29:
Het is misschien wel een idee voor de (eventuele) editor. Hele USB stick afzoeken en laten kiezen welke programma's je in je menu wilt hebben...

quote:

Lennart schreef op zaterdag 13 januari 2007 @ 10:54:
En we hebben een concurrent voor pstart Ook al heb je een hekel aan mappen, komt de mogelijkheid erin dat je minder vaak gebruikte icoons wel in een mapje kunt stoppen?

wackmaniac wijzigde dit bericht 13-01-2007 13:12 (26%)

AtleX wijzigde dit bericht 13-01-2007 19:36 (11%)

quote:

AtleX schreef op zaterdag 13 januari 2007 @ 19:32:
Voor een schoolproject moesten * AtleX & Griffin even uitzoeken hoe het precies zat met C# en SQL server 2005 qua verbinding maken etc. Daar is een testtooltje uitgerold waarmee je verbinding kunt maken en queries kunt uitvoeren op elke database in een SQL Server:

Exiss wijzigde dit bericht 13-01-2007 20:08 (23%)

quote:

wackmaniac schreef op zaterdag 13 januari 2007 @ 13:11:
Zou ik even over na kunnen denken ja, maar dan is natuurlijk wel de vraag: Hoeveel apps heb je wel niet op je USB staan dat je die in een mapje wilt stoppen?

Ik wil vanmiddag eerst de tray app wat gaan modificeren: commandline args laten accepteren, want is ik de app als autorun laat starten op mijn USB haalt hij de Settings.xml uit de root.

quote:

Exiss schreef op zaterdag 13 januari 2007 @ 20:03:
[...]
Niets tegen hetgene wat je hebt gemaakt, maar eh: Jouw school heeft geen kaas gegeten van .NET he? Zeker niet als ze zo'n opdracht opstellen voor de studenten . ADO.NET is namelijk het meest uitgelegde stuk uit het hele .NET framework en zeker niet het moeilijkste gedeelte.

quote:

Overigens kan ik niet connecten met Integrated Security en de foutafhandeling ontbreekt En nog een tip: Gebruik de gridview voor de results die je op haalt ipv een richtextbox/listbox (wat het nu ook is).

quote:

MisterData schreef op maandag 08 januari 2007 @ 17:49:
Een jingle-player, zodat ik met twee drukken op de knop bij 400+ jingles en andere geluidjes kan

pietje63 wijzigde dit bericht 29-01-2007 16:09 (4%)

quote:

Kuhlie schreef op maandag 29 januari 2007 @ 16:47:
Wat qua performance enorm helpt is als je niet bij elke keypress direct een ajax-request doet, maar juist een timer start (indien niet al gestart) die een kwart seconde later alsnog die request doet. Het is iets meer administratie, maar heeft 2 voordelen:
- het intypen is niet meer blocking
- er hoeven minder requests gestuurd te worden naar je server

pietje63 wijzigde dit bericht 29-01-2007 22:35 (11%)

quote:

Error65 schreef op maandag 29 januari 2007 @ 23:17:
Eventuele op/aanmerking zijn welkom!

RobIII wijzigde dit bericht 29-01-2007 23:37 (10%)

quote:

Error65 schreef op maandag 29 januari 2007 @ 23:17:
Ik heb samen met een vriend een simpel programmatje geschreven die op een veilige manier bestanden van diverse soorten media (Magnetic and Solid-State Memory) verwijdert. Het verwijderen gebeurt op de manier zoals door de Amerikaanse overheid wordt beschreven.

Het programma hebben we puur uit educative redenen geschreven en stellen we daarom beschikbaar voor iedereen

Voor de geintresseerden is het programma (inclusief C sourcecode) hier te downloaden.

Eventuele op/aanmerking zijn welkom!

P.S. Het programma is alleen getest op Windows, maar is in theorie ook te compilen voor Linux en MacOS (GCC)

user@host:$ shred -n 25 --remove file.tmp

quote:

RobIII schreef op maandag 29 januari 2007 @ 23:22:
[...]

Het werkt niet (waarschijnlijk)
Wie garandeert mij dat je dezelfde blocks/sectors overschrijft? Je zult toch echt eerst moeten uitvogelen op welke sectors de te overschrijven data staat en daarna die sectors overschrijven met willekeurige data. Voor zover ik weet heb je bij fwrite geen garantie dat dezelfde blocks/sectors worden ge/herbruikt en zul je dus op een lager niveau je media moeten aansturen dan met een "simpele" fwrite.

quote:

Please note that shred relies on a very important assumption: that the file system overwrites data in place. This is the traditional way to do things, but many modern file system designs do not satisfy this assumption. Exceptions include:
• Log-structured or journaled file systems, such as those supplied with AIX and Solaris, and JFS, ReiserFS, XFS, Ext3 (in data=journal mode), BFS, NTFS, etc. when they are configured to journal data.
• File systems that write redundant data and carry on even if some writes fail, such as RAID-based file systems.
• File systems that make snapshots, such as Network Appliance's NFS server.
• File systems that cache in temporary locations, such as NFS version 3 clients.
• Compressed file systems.

Electronical wijzigde dit bericht 29-01-2007 23:48 (28%)

quote:

RobIII schreef op maandag 29 januari 2007 @ 23:22:
[...]

Het werkt niet (waarschijnlijk)
Wie garandeert mij dat je dezelfde blocks/sectors overschrijft? Je zult toch echt eerst moeten uitvogelen op welke sectors de te overschrijven data staat en daarna die sectors overschrijven met willekeurige data. Voor zover ik weet heb je bij fwrite geen garantie dat dezelfde blocks/sectors worden ge/herbruikt en zul je dus op een lager niveau je media moeten aansturen dan met een "simpele" fwrite.

quote:

Electronical schreef op maandag 29 januari 2007 @ 23:46:
[...]

Dit zal het bestand 'file.tmp' 25 keer achter elkaar overschrijven met (pseudo-)random bytes en daarna verwijderen.
[...]

quote:

Please note that shred relies on a very important assumption: that the file system overwrites data in place. This is the traditional way to do things, but many modern file system designs do not satisfy this assumption. Exceptions include:
• Log-structured or journaled file systems, such as those supplied with AIX and Solaris, and JFS, ReiserFS, XFS, Ext3 (in data=journal mode), BFS, NTFS, etc. when they are configured to journal data.
• File systems that write redundant data and carry on even if some writes fail, such as RAID-based file systems.
• File systems that make snapshots, such as Network Appliance's NFS server.
• File systems that cache in temporary locations, such as NFS version 3 clients.
• Compressed file systems.

Error65 wijzigde dit bericht 30-01-2007 00:14 (23%)

quote:

Error65 schreef op dinsdag 30 januari 2007 @ 00:11:
We kunnen je (helaas) niets garanderen Maar waarom zou een OS een file verplaatsen terwijl er geen extra data bijkomt?

1

XXXXXXOOOOOXXXXXPPPPPXXXXXSXXXXX

quote:

Error65 schreef op dinsdag 30 januari 2007 @ 00:11:
Nu willen we niet beweren dat dit daarom gebeurt uiteraard, maar het lijkt ons raar. Je zeer directe antwoord doet ons vermoeden dat je hier meer over kan uitleggen?

quote:

Error65 schreef op dinsdag 30 januari 2007 @ 00:11:
Ons programma maakt slechts de eerste vier en de laaste vier ronden (van de 35) gebruik van random bytes, zoals hier staat beschreven.

quote:

Error65 schreef op dinsdag 30 januari 2007 @ 00:11:
Nu betreft het slechts een maandagavond programmatje, dus erg uitgebreid en onderbouwd is het verder niet

quote:

Error65 schreef op dinsdag 30 januari 2007 @ 00:11:
Dat hebben we niet eens gezien, maar zolang zijn we er ook niet mee bezig geweest

RobIII wijzigde dit bericht 30-01-2007 00:50 (34%)

quote:

RobIII schreef op dinsdag 30 januari 2007 @ 00:41:
[...]

Ik heb het ook niet over verplaatsen. Stel dat je bestand (enigszins gefragmenteerd) op schijf (of andere media) er zo uit ziet ( X = bestand, !X = andere data):
code:

1	XXXXXXOOOOOXXXXXPPPPPXXXXXSXXXXX

Als ik nu file O wis ("normaal") valt er een gat in; fwrite zou (intern) kunnen besluiten dat aaneengesloten blokken gunstiger zijn en bij het "overschrijven" dus de O-plekken kunnen gebruiken, waarbij (bijvoorbeeld) de laatste blokken van X blijven staan (maar non-referenced in je MFT).


[...]

Het probleem zit 'm in het feit dat je de aanname doet dat fwrite dezelfde blokken ge/herbruikt en dat hoeft niet zo te zijn. Daarnaast is er ook nog eens (inderdaad) het probleem met (o.a.) journaling filesystems en shadow copies.

Wil je zeker weten dat je een file "secure" verwijdert dan zul je gewoon moeten zorgen dat je 100% zeker weet dat je alle juiste blokken wist/overschrijft en geen aannames doen. Vind je een 80% "gewist" bestand acceptabel; be my guest, maar ik wil, als ik iets "secure delete" het ook écht helemaal verwijderen en niet een beetje of "hopen dat...".