English | Magyar
JS ki | CSS ki | Ékezetek ki | HiContrast
Lapozó:  (0 - 1424) 
<== | ==>
Ugrás a végére | Összes megjelenítése | Utolsó oldal
OpenOpera patches | Opera-SSL patches | Opera 12.15 source (Git repository) | Opera 12.15 source (Torrent) | Opera internal pages | Otter Browser Linux x64 - Qt5.15.2/QtWebKit5.602.1 (2024.04.27. 20:05)
OS for MC680x0 | OS for PPC | OS for Sparc64 | besztofbégéaefcé | CSÉNDZSLOG | WebToolz | DDG Shit Filter | Google Shit Filter | Progz | Fast CSS Box | Browser | OS | Agent | Statisztika | BBCode
Monospace font-family: Courier New | Browser default monospace
Email értesítő / Email notification ===> 
Keresés
Σ: 16 post

TCH  (statz) Főfasz
#1, Főfasz (10443)
609 | #1740 | ^ | Idézet | Sun, 23 Oct 2011 12:09:35 +02
46.107.*.* Unknown Unknown Hungary *.catv.pool.telekom.hu
Pety: Bannold ki az userét, lehet olyat jutúbon, nem?
Vendégkönyv 3.6.0:
  • Leesett mi volt az oka, hogy ha post után frissítünk miért küldi el megint...mert post után nem volt redirect, hanem elmentette aztán legenerálta az oldalt. :P Ezer sorry meg egy félbetépett jegesmedve. Fixálva.
  • IP ban átírva, innentől a bannolt IP címeket nem csak postolni nem engedi, hanem semmit sem, a jó öreg "anyád/fuku" felirattal távoztatja el őket.
  • Postszerkesztésnél kikapcsoltam a 30 seces várakozási időt, ott nincs értelme. De ez titeket nem érint, csak kemit meg engem.


kemi  (statz) Főfasz
#2, Főfasz (2970)
574 | #1741 | ^ | Idézet | Sun, 23 Oct 2011 13:03:50 +02
178.164.*.* Unknown Unknown Hungary *.pool.digikabel.hu
djpety írta/wrote:
Na ákoska próbálkozik, már a youtube videómon kérdezősködik... Nem könnyű lerázni :D
Még itt is itt van, csak be van tömve a pofája. :D
TCH írta/wrote:
IP ban átírva, innentől a bannolt IP címeket nem csak postolni nem engedi, hanem semmit sem, a jó öreg "anyád/fuku" felirattal távoztatja el őket.
A vendégkönyvet miért ne nézhetné? Postolni úgyse tud.

TCH, lehet hogy csak 16:15-re leszek ott, majd meglátom, és még szólok. szerk: az előző kijelentésem valid bitje 0. Megyek.


TCH  (statz) Főfasz
#1, Főfasz (10443)
103 | #1742 | ^ | Idézet | Sun, 23 Oct 2011 14:52:04 +02
46.107.*.* Unknown Unknown Hungary *.catv.pool.telekom.hu
Postolni nem tud, de nem kell, hogy napi 50 megányi szemetet generáljon. Meg hogy érezze a törődést. :)


kemi  (statz) Főfasz
#2, Főfasz (2970)
251 | #1743 | ^ | Idézet | Sun, 23 Oct 2011 19:52:52 +02
178.164.*.* Unknown Unknown Hungary *.pool.digikabel.hu
A BGAFC csatornára szemetelt a vodkafonos, nem az enyémre, és szóltál is hogy töröljem ki. Sajnos már nincs meg, és a logokat se lehet megnézni, abból talán kiderülne a júzuerneve.

szerk: viszont ákoska kidobva és bannolva.


TCH  (statz) Főfasz
#1, Főfasz (10443)
384 | #1744 | ^ | Idézet | Sun, 23 Oct 2011 21:42:53 +02
46.107.*.* Unknown Unknown Hungary *.catv.pool.telekom.hu
kemi írta/wrote:
A BGAFC csatornára szemetelt a vodkafonos, nem az enyémre, és szóltál is hogy töröljem ki.
Ja, tényleg, erre emlékszem. Nem baj, azt én anno megnéztem, ugyanúgy egy semmitmondó név volt, sose bánd.
kemi írta/wrote:
szerk: viszont ákoska kidobva és bannolva.
Na, egy gonddal kevesebb. :)


saxus  (statz) Agyfasz
#9, Agyfasz (419)
1287 | #1745 | ^ | Idézet | Sun, 23 Oct 2011 22:33:55 +02
84.3.*.* Unknown Unknown Hungary *.catv.pool.telekom.hu
"Elég ha beteszik egy csomagfájlba és akkor ott is nextnextnext. Jóreggelt winfoson meg OSX-en valid dolog az installer (msi meg nem tom mi van osx-en) Linuxon meg invalid a deb, rpm, meg a többi? Hát ez tényleg kettős mérce."

Szövegértés egyes: pont azt magyarázom, hogy OSX-en is lekapsz egy .dmg (disk image, kb. mountolhato iso) vagy egy .mpkg-t (kb. msi) és csodák-csodájára működik, pedig 3rd party cucc. Ubuntun meg ott a csudacsomagkezelő olyan szoftverekkel, amit a Canonical szállít, és hogy-hogy nem mégis érik az embert meglepetések: mondjuk összeakad egy másik - szintén a canonical által szállíott - csomaggal.

"Ez a videó volt téma a spiriten is, ez az ARM architektúra egyik reklámja. "

Mondjuk az ARM meggyőző lehetne, ha raknának alá rendes memóriabuszt. Multkor hupon volt egy thread, hogy mekkora fasza az ARM lassan már behozza a 4 évvel ezelőtti Core2Duo-k sebességét. Igen, csak egy szintetikus tesztprogramban, amelynek a kódja nincs 16 kb és dolgozik 2000 byte adaton...

... ami még egy P1-es L1 cachejébe is belefér. Aztán a még NDA alatt álló cuccok sem érnek memória sávszélben a normál CPU-k közelébe és ilyen egyéb dolgokat, mint h.264 en/decoding is csak célhardverrel tudják. Nah, így azért nehéz lesz elérni az ARM világuralmat ;)


TCH  (statz) Főfasz
#1, Főfasz (10443)
4448 | #1746 | ^ | Idézet | Sun, 23 Oct 2011 23:02:41 +02
46.107.*.* Unknown Unknown Hungary *.catv.pool.telekom.hu
saxus írta/wrote:
Szövegértés egyes: pont azt magyarázom, hogy OSX-en is lekapsz egy .dmg (disk image, kb. mountolhato iso) vagy egy .mpkg-t (kb. msi) és csodák-csodájára működik, pedig 3rd party cucc.
Hát lehet, hogy félreértettem valamit abból amit írtál
saxus írta/wrote:
Arról az apróságról meg ne feledkezzünk meg, hogy az Ubuntu az meg ugye maga szállítja a programokat, lényegében, mint a terjesztés része, szemben az Appleval, ahol ugyanúgy mehet két kattintással bármi 3rd party cucc, mint pl. Windowson.
de néha elég zavarosan fogalmazol.
Third party cuccok buguntun is szoktak menni, van amelyik csomagolás nélkül is. Ha arra célzol, hogy a kernel API állandó átvariálása miatt állandó inkompatibilitási fasságok vannak, azt tudom. Újfennt: én nem akarom azt állítani, hogy a xy Linux jobb mint az OSX. Csak azt mondom, hogy amiket felhoztál, azok nem szükségszerűek. Én pl. mindig az LTS-t használom és a szopásaimnak a 100%-a valamilyen bug vagy konfig mizéria miatt volt és nem pedig regressziók és a kernel API átvariálása miatt. Tudom, hogy sokan szopnak ilyesmivel, de arra is van precedens, hogy faszán megy.
És nincs hathavonta random szopás, vagy helyette LTS-en kézzel taknyolás. (?m=0&o=4050&c=1 Nekem is flawless frissítés volt a 8.04=>10.04)

De figy, aggyá melót az empónál, lesz pénzem veszek én is egy Mac-et, oké? :P Nekem totál mindegy, csak ne winfos legyen. (Meg nem árt, ha van programválaszték.)
saxus írta/wrote:
Nah, így azért nehéz lesz elérni az ARM világuralmat ;)
A kutya nem beszél világuralomról, egyébként az ARM-ot rohadtul nem oda szánták/szánják, ahol brutál teljesítményre van szükség, hanem oda, ahol kevésből kell elérni valamit; embedded cuccok, okostelefon, faszomtudja.
A sux86-nak a POWER az igazi alternatívája, de azt meg már nem raknak desktop gépbe, csak űrrakétába, marsjáróba, meg szuperszámítógépbe. Utóljára a PS3-ba került egy POWER (Cell) proci, de csúfosat buktak vele, mert nem tudták kihasználni.
kemi, elfelejtettük megnézni, hogy mit csinál a rand(). Mondjuk nem vesztettünk semmit vele, mert most kidumpoltam mit csinál a következő C kód:
void main()
{
	rand();
}
	.file	"faszombeled.c"
	.text
.globl main
	.type	main, @function
main:
	pushl	%ebp
	movl	%esp, %ebp
	andl	$-16, %esp
	call	rand
	movl	%ebp, %esp
	popl	%ebp
	ret
	.size	main, .-main
	.ident	"GCC: (Ubuntu 4.4.3-4ubuntu5) 4.4.3"
	.section	.note.GNU-stack,"",@progbits
és ezzel kitörölhetjük a seggünket. :)
Meg kéne nézni valahol, hogy a rand minek a része (kernel, libc) és megnézni a forrást.

Ja és közben eszembe jutott, hogy az RC-ben igazából feleslegesen generálunk le egy táblát, amikor simán az is elég, hogy véletlenszámot adunk hozzá vagy veszünk el belőle:
Procedure rcrypt(ptr0, ptr1: ^Byte; size, key: Longword; dir: Boolean);
var
	i: Longword;
	b: Byte;
Begin
	RandSeed := key;
	For i := 1 To size Do
	Begin
		b := Random(255);
		If (dir) Then
		Begin
			ptr1^ := ptr0^ + b;
		End
		Else
		Begin
			ptr1^ := ptr0^ - b;
		End;
		Inc(ptr0);
		Inc(ptr1);
	End;
End;
Teljesen ugyanolyan visszafejthetetlen, mintha egy táblából olvasnám ki, hogy hanyadik helyen van, vagy az ehanyadik helyen mi van.

De az is eszembe jutott, hogy még ha le is akarjuk generálni a táblákat, akkor nem kell végiggenerálni a táblát, csak
a) addig amíg megegyezik a kapott véletlenszám a beolvasott értékkel
b) 0-tól a beolvasott szám értékéig
lévén ugye minden byte-ra egyedi jutna, azaz a táblát a következő körben dobhatjuk el úgyis.
var
	tbl: Array[0..255] of Byte;

Function NotInTBL(data, last: Byte): Boolean;
var i: Integer;
Begin
	For i := 0 To last Do
	Begin
		If (tbl[i] = data) Then
		Begin
			Result := False;
			Exit;
		End;
	End;
	Result := True;
End;

Procedure rcrypt(ptr0, ptr1: ^Byte; size, key: Longword; dir: Boolean);
var
	i: Longword;
	b, c, j: Byte;
Begin
	RandSeed := key;
	For i := 1 To size Do
	Begin
		b := ptr0^;
		If (dir) Then
		Begin
			j := 0;
			Repeat
				c := Random(255);
				If (NotInTBL(c, j)) Then
				Begin
					tbl[j] := c;
					Inc(j);
				End;
			Until (c = b);
			c := j;
		End
		Else
		Begin
			j := 0;
			Repeat
				c := Random(255);
				If (NotInTBL(c, j)) Then
				Begin
					tbl[j] := c;
					Inc(j);
				End;
			Until (j = b);
		End;
		ptr1^ := c;
		Inc(ptr0);
		Inc(ptr1);
	End;
End;


saxus  (statz) Agyfasz
#9, Agyfasz (419)
227 | #1747 | ^ | Idézet | Mon, 24 Oct 2011 01:39:52 +02
84.3.*.* Unknown Unknown Hungary *.catv.pool.telekom.hu
"embedded cuccok, okostelefon, faszomtudja."

Nah ez a vicc, ARM megpróbál feltörni a desktop piacra. Igazából nem is teljesen reménytelen, már ha a nettó számítási teljesítményt nézzük, csak a körítés egyelőre kevés.


kemi  (statz) Főfasz
#2, Főfasz (2970)
530 | #1748 | ^ | Idézet | Mon, 24 Oct 2011 10:50:43 +02
178.164.*.* Unknown Unknown Hungary *.pool.digikabel.hu
TCH: valszeg OS rutint hív meg, az gyanítom valami modulo osztások sorozatát csinálja. A pszeudorandommal az a baj, hogy az kurvára determinisztikus, és ha determinisztikus törhető. Amúgy a kulcs is, akármennyire sztringből generáltuk le, az lehet 64k darab szám, ami egy mai pécének nem sok. Fél nap alatt brute force-szal is fel lehet törni. Meg mi van, ha több seedre is ugyanazt a szekvenciát generálja? Akkor még hamarabb fel lehet törni.
SID chip tesztelésére létezik valami program? Mintha nem szólna nálam egy csatorna.


TCH  (statz) Főfasz
#1, Főfasz (10443)
1839 | #1749 | ^ | Idézet | Mon, 24 Oct 2011 14:39:17 +02
46.107.*.* Unknown Unknown Hungary *.catv.pool.telekom.hu
saxus írta/wrote:
csak a körítés egyelőre kevés.
Annyira nem. Én egyelőre nem mondok semmit, mert lehet, hogy sikerül az ARM-nak, lehet, hogy nem.
kemi írta/wrote:
A pszeudorandommal az a baj, hogy az kurvára determinisztikus, és ha determinisztikus törhető.
Törhető a nyavalyát. Akkor lehetne törhető, ha ismernéd a bemeneti értéket, de azt nem ismered. Az igazi véletlenre pedig nem lehet visszafejthető titkosítást írni, a mi cuccunk pedig nem hash, hanem titkosító, amit vissza kell tudni fejteni.
A kulcs pedig nem 64k, hanem 4G, így aztán egy jó hosszú fájlon végigpróbálni mind a 2x4 milliárd kombinációt (mert ugye az RC két irányú), az jó sokáig fog tartani.

De van más titkosítási mód is ami vérprimitív és mégis kurva jó. A hashekhez hasonló rotálás, kizáró vagyolás, az se rossz.
Procedure xorcrypt(ptr0, ptr1: ^Byte; size: Longword; password: String);
var
	i, j: Longword;
Begin
	j := 1;
	For i := 1 To size Do
	Begin
		ptr1^ := ptr0^ Xor Ord(password[j]);
		Inc(j);
		If (j > Length(password)) Then
		Begin
			j := 1;
		End;
	End;
End;
Na ezt aztán végképp fejtse vissza akinek hat anyja van, mert itt a kulcs nélkül az embernek gőze nincs, hogy mikor hol, mivel kell xorolni. Itt ugyanis közvetlenül a kulcs byte-jaival fog kizáró vagy kapcsolatot csinálni. Vagyis ahhoz, hogy visszafejtse az egészet összesen size256 kombinációt kéne végigpróbálni, ami már viszont irdatlan idő és ráadásul nem is tudja, mikor kapott vissza jó eredményt. És ugye ezt is lehet rétegelni, azaz ugyanazt a folyamot más-más kulccsal eltitkosítani egymás után.
http://chipmusic.org/forums/topic/867/how-can-i-test-a-sid/
Itt írnak egy bézikprogramot amit ki lehet próbálni. De szerintem lehet majd írok én egyet 6502-ben, oszt csá.


TCH  (statz) Főfasz
#1, Főfasz (10443)
1281 | #174a | ^ | Idézet | Mon, 24 Oct 2011 15:39:29 +02
46.107.*.* Unknown Unknown Hungary *.catv.pool.telekom.hu
rand(): http://koala.cs.pub.ro/lxr/#glibc+2.9/stdlib/rand.c#L26
int rand ()
{
	return (int) __random ();
}
Csak egy másik függvény. Nézzük azt.
long int __random ()
{
	int32_t retval;
	__libc_lock_lock (lock);
	(void) __random_r (&unsafe_state, &retval);
	__libc_lock_unlock (lock);

	return retval;
}
Aham egy újabb meghívás. :) Nézzük azt a random_r-t.
int __random_r (buf, result)
	struct random_data *buf;
	int32_t *result;
{
	int32_t *state;

	if (buf == NULL || result == NULL)
	goto fail;

	state = buf->state;

	if (buf->rand_type == TYPE_0)
	{
		int32_t val = state[0];
		val = ((state[0] * 1103515245) + 12345) & 0x7fffffff; // hat ez tiszta xkcd :D
		state[0] = val;
		*result = val;
	}
	else
	{
		int32_t *fptr = buf->fptr;
		int32_t *rptr = buf->rptr;
		int32_t *end_ptr = buf->end_ptr;
		int32_t val;
	
		val = *fptr += *rptr;
		/* Chucking least random bit.  */
		*result = (val >> 1) & 0x7fffffff;
		++fptr;
		if (fptr >= end_ptr)
		{
			fptr = state;
			++rptr;
		}
		else
		{
			++rptr;
			if (rptr >= end_ptr)
			rptr = state;
		}
		buf->fptr = fptr;
		buf->rptr = rptr;
	}
	return 0;

	fail:
	__set_errno (EINVAL);
	return -1;
}


kemi  (statz) Főfasz
#2, Főfasz (2970)
200 | #174b | ^ | Idézet | Mon, 24 Oct 2011 18:50:58 +02
178.164.*.* Unknown Unknown Hungary *.pool.digikabel.hu
Amit fentebb írtál az úgy jó, ha a kulcs legalább akkora mint a titkosítandó folyamat, és random. (de nem pszeudorandom!) Az a one time pad. Na ha azt feltöröd akkor Nobel díjat kapsz az garantált. :D


TCH  (statz) Főfasz
#1, Főfasz (10443)
324 | #174c | ^ | Idézet | Mon, 24 Oct 2011 22:15:38 +02
46.107.*.* Unknown Unknown Hungary *.catv.pool.telekom.hu
Nyilván minél hosszabb a kulcs, annál jobb, de mondjuk, ha a kulcs az, hogy "Kurva anyját bilgécnek!", akkor már azzal is elég hatékonyan el lehet titkosítani bármit. De lehet valóban akár azt is, amit te mondasz, hogy van egy random generált kulcsa az embernek, mondjuk olyan 4k méretű, na az is elég jó már.


TCH  (statz) Főfasz
#1, Főfasz (10443)
129 | #174d | ^ | Idézet | Tue, 25 Oct 2011 00:12:10 +02
46.107.*.* Unknown Unknown Hungary *.catv.pool.telekom.hu
Flood3r: Most jövök a retrovisionról, mi lett a fórummal? Elszublimált?
Apropó szublimáció, Prometheus is elszublimált újfenn. :(


TCH  (statz) Főfasz
#1, Főfasz (10443)
2239 | #174e | ^ | Idézet | Tue, 25 Oct 2011 16:02:25 +02
46.107.*.* Unknown Unknown Hungary *.catv.pool.telekom.hu
Próbafeladat közben összeakadtam egy problémával, mégpedig, hogy ki kéne törölni a dupla bejegyzéseket egy kapcsolótáblából. Oké, hogy insert ignore on duplicate key, de a bibi az, hogy nem insertkor kerül bele a duplicate key, hanem updatekor, ugyanis akik kérték azt kérték, hogy a kategória törlésekor az oda kapcsolt bejegyzések kerüljenek át a default kategória alá és sajna ahogy nézem update nem tudja ugyanezt az ignore dolgot.
		@mysql_unbuffered_query('DELETE FROM cat WHERE id="'.$_GET["delid"].'"');
		@mysql_unbuffered_query('UPDATE cim_cat SET cat_id="0" WHERE cat_id="'.$_GET["delid"].'"');
Ennyi a kód, ami csinálja a duplikált sorokat. Értelemszerűen duplikáció akkor keletkezik, amikor a 0 alá is be van rendelve egy bejegyzés és törléskor a törölt kategória alatti bejegyzés átkerül oda. Szemléltetem:
Előtte:
cim_idcat_id
10
11
12
13
20
21
22


Aztán lefut ez a vacak mondjuk a 2-es kategóriára:
cim_idcat_id
10
11
10
13
20
21
20
Teccikérteni? Persze a megjelenítőnek mindegy, annak egyszeri szereplés elég, de nem akarok redundáns sorokat.
Találtam a neten egy megoldást (http://www.justin-cook.com/wp/2006/12/12/remove-duplicate-entries-rows-a-mysql-database-table/), ami alapján ezt hoztam ki:
function throwduplby($table, $field)
{
	@mysql_unbuffered_query('CREATE TABLE tmp AS SELECT DISTINCT * FROM '.$table);
	@mysql_unbuffered_query('DROP TABLE '.$table);
	@mysql_unbuffered_query('RENAME TABLE tmp TO '.$table);
}
Nekem ez azonban eléggé gánynak tűnik. Valami alternatív megoldás a duplikációk törlésére esetleg? Vagy esetleg teljesen másképp kéne megközelíteni már a törlést is?


kemi  (statz) Főfasz
#2, Főfasz (2970)
265 | #174f | ^ | Idézet | Tue, 25 Oct 2011 21:00:58 +02
78.131.*.* Unknown Unknown Hungary *.pool.hdsnet.hu
Ha volna egy elsődleges kulcs akkor aszerint könnyű kitörölni, egyébként meg végig kéne menni két kurzorral a táblán, összehasonlítgatni a sorokat, ha valamelyik kettő egyezik az egyiket kitörölni.

Ez kurva jó!


English | Magyar
JS ki | CSS ki | Ékezetek ki | HiContrast
Lapozó:  (0 - 1424) 
<== | ==>
Ugrás a végére | Összes megjelenítése | Utolsó oldal
OpenOpera patches | Opera-SSL patches | Opera 12.15 source (Git repository) | Opera 12.15 source (Torrent) | Opera internal pages | Otter Browser Linux x64 - Qt5.15.2/QtWebKit5.602.1 (2024.04.27. 20:05)
OS for MC680x0 | OS for PPC | OS for Sparc64 | besztofbégéaefcé | CSÉNDZSLOG | WebToolz | DDG Shit Filter | Google Shit Filter | Progz | Fast CSS Box | Browser | OS | Agent | Statisztika | BBCode
Monospace font-family: Courier New | Browser default monospace
Email értesítő / Email notification ===> 
Keresés

Név: (max 255 byte)

Email: (max 255 byte) Nem kötelező!

Üzenet: (max 65536 kar.) 65536-0=65536




crap_vkn v4.34.0 by TCH
Thx to saxus for the escaped string decoder function (PHP), the realIP function (PHP) & the SQL handle layer (PHP), to thookerov for the int_divide function (PHP), to Jeff Anderson for the getSelText function (JS), to Alex King for the insertAtCursor function (JS), Flood3r for the new CSS styles, Pety for the spamprotection idea and some design and comfort ideas, MaxMind for the IP2Country database, famfamfam for the flags of countries and an unknown PHP programmer for the removeAccents function.



Kecskebaszók ide!