Messages posted by: rongchaua

Hic.... Microsoft nó "thù" Linux mà bạn kêu nó gói Linux vào sao được hả bạn. smilie

).

Câu hỏi đặt ra là: việc thiết lập trên đã cải thiện những gì trong communication giữa trụ sở và chi nhánh? Như thế nào? Và tại sao?.

Hên xui. Với kiểu bias random 1:3 này thì 25% packet sẽ chạy với tốc độ đường truyền cũ và 75% chạy với tốc độ đường truyền mới. Ví dụ trong trường hợp xui: gởi 1 file đi, 1/4 file chạy bên line cũ, 3/4 còn lại chạy bên line mới. 3/4 file tới trước ngồi chờ 1/4 file tới sau để góp lại đủ 1 file. Thì coi như cả đám chạy với tốc độ đường truyền cũ. Trường hợp hên thì cả đám chạy trên line mới thì tới nhanh hơn. Vi hên xui như vậy nên trong trường hợp xui thì cũng chạy ít nhất với tốc độ line cũ (bỏ qua thời gian xử lý của router) còn hên thì chạy với tốc độ line mới cho nên là có cải thiện. Nhưng cải thiện bao nhiêu thì ... hem biết. smilie

.

To choc_: Mình thì hiểu theo khái niệm bên truyền thông tin viễn thông và mình nghĩ khái niệm Integrity nó có từ rất lâu từ khi bắt đầu truyền dẫn. Lúc đó khái niệm Integrity chỉ đơn thuần là bảo đảm tính trọn vẹn (đúng đắn) của dữ liệu. Tức là gói tin đi tới bị lỗi truyền dẫn, yêu cầu gởi lại. Thế là xong. Có lẽ là khái niệm đó bây giờ bao gồm cả xác thực nguồn tin.

To choc_: Xin lỗi nếu mình chậm tiêu, nhưng mình hiểu là đơn nghĩa của từ Integrity là tính toàn vẹn. Tức là các checksum đảm bảo là là dữ liệu không bị thay đổi (chủ quan lẫn khách quan) trên đường truyền. Do đó các checksum (dưới mọi hình thức) đều đảm bảo tính Integrity. Tức là dữ liệu nhận được chính là dữ liệu ở phần gởi.
Trong ví dụ choc_ đưa ra dù mình có down file X' vớ checksum là A' thì cái A' đó nó chỉ nói đến cái integrity của cái X'. Tức là nếu mình down file về là checksum của nó là A' thì chắc chắn là file X'. Còn việc nó đã bị fake thì mình nghĩ nó đâu có liên quan gì tới Integrity.
Còn nếu như theo choc_ giải thích thì Integrity nó phải đảm bảo được cả phần gởi phải chính xác. Tức là bao gồm cả việc xác thực nguồn tin. Như vậy liệu là nó có vượt quá sự định nghĩa của từ Integrity hay không?

Nếu đã có sự xuất hiện của một active man-in-the-middle rồi thì chẳng có nguồn nào là đáng tin cậy (nếu không có cơ chế kiểm tra chữ ký hay MAC này nọ). Cái ý tưởng attack ở đây là mình đã thay đổi luôn cái md5sum rồi, nên md5sum mà bạn thấy thực ra không phải md5sum ban đầu.

Không hiểu là ý bạn choc_ đang nói đến integrity của message hay reliability của message? Bởi vì bạn có nói với Z0rr0 là "mình chưa thấy ai sử dụng checksum như là một cách để bảo vệ Integrity cả." nên mình không hiểu lắm. Integrity là chỉ tính toàn vẹn của dữ liệu. Tức là nó dùng để kiểm tra dữ liệu có thay đổi trên đường truyền hay không? Như bạn choc_ cũng đã nói là khi thay đổi dữ liệu thì md5sum thay đổi thì sau khi dữ liệu đến máy của mình thì mình so lại sẽ thấy md5sum thay đổi thì mình biết dữ liệu đã bị thay đổi trên đường truyền. Tức là mình là dùm checksum để kiểm tra tính Integrity. Vậy nếu không dùng checksum để kiểm tra tính Integrity thì mình cũng không biết có cách nào khác để kiểm tra nữa.

Cảm ơn choc_ các link về tấn công md5.

nếu mà attacker muốn, thì họ có thể vừa thay đổi cái file mà bạn download về, vừa tính lại checksum, thì cũng chẳng ai biết. việc này là làm được hoàn toàn, chẳng có gì là ghê ghớm cả.

Cho mình hỏi bạn choc_ ở đoạn này. Ý bạn choc_ là có thể "làm lại" cái file để nó có lại cái checksum như cũ sau khi sửa chữa? Ví dụ là mình cần 1 file từ 1 nguồn tin cậy. Tuy nhiên mình không download được file mà chỉ có md5 của file đó. Bạn mình lại có file đó, nó gởi cho mình. Vậy nó có thể thay đổi file đó và tạo lại một checksum md5 y chang như file của nguồn tin cậy? Nếu ý bạn chọc là như vậy thì có thể cho giới thiệu cho mình tên cái tool đó được không. Vì mình chỉ thấy regenerate file để có được checksum CRC32 chứ MD5 thì mình chưa thấy.

http://rapidshare.com/files/221303711/MEMORY.rar

Của lão Thug nè. Lỗi màn hình xanh.

Vào Menu Options --> Appearance --> Directories. Chỉnh lại UDD Path là oki.

Hi lão Lê,
theo ý lão rồng thì hãy xét về bản chất của VK là được tạo ra để chống Keylogger chứ không phải để chống Clicklogger. Cho nên dù VK có cải tiến cách mấy thì cũng không qua được Clicklogger vì nó không được tạo ra để chống Clicklogger. Giống như kêu cải tiến thuốc chữ "táo bón" để chữa được luôn "tiêu chảy" thì cũng hơi khó...khó...
Còn giải pháp thì có sao để vậy đi. Như theo ý kiến của lão là cài một cái anti-screen-capture vậy nếu dùng 1 cái anti-virus free luôn thì sẽ an toàn hơn. Dù gì cũng phải cài ở client 1 phần mềm đó mà. smilie

.

Cũng chỉ là thao tác căn bản thôi mà các bác. Bất cứ người dùng Windows nào cũng phải biết

Đó chỉ là lý thuyết bạn đặt ra thôi. Mà lý thuyết thì nó xa thực tế cả ngàn dặm đó bạn àh.

Có 2 cuốn C# mà mình thấy nên đọc:
+ Programming C# của Jesse Liberty.
+ C# Design Pattern của Judith Bishop.

Hai cuốn đó bạn có thể xem tại đây
http://gallery.rongchaua.net/main.php?g2_itemId=428

Network latency là thuật ngữ chung dùng để chỉ các loại delay tiêu biểu xảy ra trong quá trình xử lý dữ liệu của network. Thời gian delay càng thấp thì chỉ số Network latency sẽ thấp.

Thông thường để tối ưu (giảm) thời gian delay thì về phía user nên tắt bớt các chương trình sử dụng đến traffic network không cần thiết đi. Về phía network thì dùng traceroute để xác định đâu là chỗ gây ra delay lớn nhất và cố gắng tối ưu hoặc re-route nó qua một con đường khác.

Trong trường hợp của bạn thì bạn thử search với Google để coi có cao nhân nào đã giảm được cái network latency để sử dụng cho phần mềm đó chưa? Nếu chưa có thì bạn tìm hiểu xem coi chương trình nó làm sao để test Network latency, rồi tối ưu những đoạn delay lớn nhất để cho thời gian delay tổng cộng sẽ dưới 300 ms.

Hi HaiNam.No.Other,
theo ý mình thì ở lớp Physical Layer PDU chính là các bit. Bởi vì các bit Data ở lớp Physical Link sẽ thành SDU cho lớp Data Link. Hinh sau đây thể hiện khá rõ ràng:

Còn PCI ở lớp Physical Layer thì bao gồm các thông tin như Preamble Sequence, Start of Frame Delimiter...

Ồh, StarGhost có thể post đoạn code bạn dùng cho mình xem được không?

@nbthanh: Cám ơn cho câu trả lời rõ ràng của bạn. Chính xác tới độ con mắt.

dẫu vậy, mình tin là một tí nữa, bạn rongchaua sẽ bị bạn nbthanh làm nhục

Cũng đã nhục rồi. smilie

). Tuy nhiên mình đã edit bài. Không đáng để nói nặng nhau như vậy. Vả lại đã tối và vừa mới coi qua các bài viết của nbthanh. Kiểu viết là thế. smilie

).
Dù gì bạn đã ra câu hỏi thì cũng cho mình xin câu trả lời. Tại sao lại có lớp Integer khi đã có biến primitive int? Áp dụng cho Java phiên bản mới nhất nhé. smilie

.
Thôi đi ngủ phẻ.

Edit nội dung mod xóa dùm.

Đó chỉ mới giới thiệu về lớp Integer chứ chưa trả lời cho câu hỏi "tại sao lại phải có lớp Integer khi đã có kiểu primitive int?".

Nếu bạn biết câu trả lời thì chỉ cần đơn giản là gõ vào câu trả lời là được. Tui thấy dạo này trên HVA có cái ngộ là trả lời bằng 1 câu hỏi khác. Kiểu như đánh đố hay để chứng tỏ cái gì đó thì phải. Vừa mất thời gian người đọc mà chẳng giúp được gì với câu trả lời kiểu này. Và riêng cá nhân tôi thì coi cái "kiểu" trả lời này là spam. .
Sẵn tiện thêm 1 link về Integer và int http://mindprod.com/jgloss/intvsinteger.html

Bạn có thể cho cái ví dụ về "1 byte array và cho ra ở phía đầu ra là 1 integer string" được hông ?

Cụ thể thì như mình đã nêu ở bài trên ví dụ có byte array {0x1f,0xf3} thì đầu ra sẽ thành 499 <-- integer string. còn Array {0x3e,0xd6} thì đầu ra nó thành 16086 <-- integer string. Tức là hiện tại chỉ là đơn giản chuyển từ HEX-->DEC qua cách đổi hệ số.
Giờ thì mình đang tìm cách khác để chuyển vì kiểu đổi cơ số như thế này thì ví dụ lấy 1 file nặng vài MB đọc vào dạng byte array dùng kiểu chuyển cơ số như thế này thì chắc làm cả tiếng chưa parse xong 1 byte. smilie

.

Àh mình chỉ đơn giản là covert từ hex sang integer thôi. Tức là 0x1f3 = 499, 0x3ed6=16086... Còn mình dùng 7 bytes là vì với 7 bytes ở Hex 0xFFFFFFFFFFFFFF thì max value bên Dec sẽ là 72057594037927935. Tức là từ 7 bytes ở Hex khi chuyển qua Dec sẽ là 17 bytes (mỗi bytes đại diện cho 1 ký tự). Mức độ phình dữ liệu sẽ là 17/7=2.43 tức là nhỏ nhất so với parse với số lượng byte khác. Ví dụ: Parse 1 byte độ phình sẽ là 3 vì max 1 byte là 255 (3 ký tự), parse 2 byte độ phình sẽ là 2.5 vì max của 2 byte là 65535 (5 ký tự).
Mình cũng chưa tìm ra cách nào tối ưu hơn. Mình chỉ cần 1 giải thuật nào đó nhận đầu vào là 1 byte array và cho ra ở phía đầu ra là 1 integer string. Và có thể dịch ngược lại integer string đó ra byte array.

Bạn đã thử dùng gmp chưa?

Chưa.

Giờ thử trả lời câu hỏi, tại sao lại có lớp Integer này nhỉ, khi mà mình nhớ không lầm thì Java đã có primitive type là int mà ta :-p?

Thôi để mình trả lời luôn. Để khỏi mất thêm 1 tháng.

The Integer class wraps a value of the primitive type int in an object. An object of type Integer contains a single field whose type is int.
In addition, this class provides several methods for converting an int to a String and a String to an int, as well as other constants and methods useful when dealing with an int.

To widman: Xem thêm ở đây http://java.sun.com/j2se/1.3/docs/api/java/lang/Integer.html .

Thật tế là mình thấy lecture notes của các khóa crypto của nhiều trường viết rất tốt về các mảng đề tài này, nhưng chẳng hiểu sao lúc viết thành sách crypto thì chẳng ai buồn thêm chúng vào.

Bởi vì một cuốn sách hay là phải thể hiện được cái mới trong đó. Do đó những kiến thức căn bản (như Information Theory của Shannon) sẽ để lượt bỏ hết để dành chỗ hay cho cuốn sách.

Tiện thể cho mình hỏi về vấn đề này. Mình đang làm luận văn về đề tài Steganography. Có 1 phần trong đó mình cần phải improve performance đó là chuyển từ 1 byte array dạng Hex sang một integer string. Tức là đầu vào là một byte array dạng Hex như {0x32,0xff,0xd3,0x3f,0x21,0xa9...} mình cần phải chuyển nó thành dạng integer string như {3442323478905505}. Hiện tại mình cũng đã làm 1 giải thuật đọc từng block 7 bytes Hex vào và parse thành một integer string 17 digits. Nhưng cách này rất chậm, đặc biệt nếu áp dụng cho các file lớn chừng vài trăm kbytes là chạy lâu thôi rồi luôn. Không biết có bạn nào có biết cách nào khác để chuyển HEX-->DEC không?

Do nhu cầu đọc thông tin ở báo, blog và forum nên mình cần như sau:
1. Một trang web quản lý tin theo cá nhân tức là có login với username và password.
2. Trang web sẽ gồm 3 mục đọc RSS. Các link RSS do user tự nhập vào.
3. Mục RSS từ báo, mục RSS từ blog và mục RSS từ forum.
4. Mục RSs từ báo thì phải remove duplicates dựa theo titlte và link. Mục RSS từ blog thì có sao để vậy. Mục RSS có khả năng tự động login vào forum và get new post. Username và password của forum đó thì user sẽ cung cấp.

Vậy thui, để khỏi mất công mỗi sáng vậy phải vào cả đống trang để duyệt tin. smilie

).
Thân.

Hì hì, XOR và cộng/trừ cũng như Caesar cipher đều là stream cipher thôi, điểm khác nhau duy nhất là chúng hoạt động trên các group khác nhau

Theo Wiki:

In cryptography, a stream cipher is a symmetric key cipher where plaintext bits are combined with a pseudorandom cipher bit stream (keystream), typically by an exclusive-or (xor) operation

n cryptography, a Caesar cipher, also known as a Caesar's cipher, the shift cipher, Caesar's code or Caesar shift, is one of the simplest and most widely known encryption techniques. It is a type of substitution cipher in which each letter in the plaintext is replaced by a letter some fixed number of positions down the alphabet

Mình tô đen sự khác biệt và lưu ý http://en.wikipedia.org/wiki/Stream_cipher ở phần Comparison Of Stream Ciphers, Caesar không xếp cùng loại.

Tôi viết bài trước là muốn nói rằng bác không cần thiết phải thử với OR vì hiển nhiên là không được.

Mình chưa thấy stream cipher nào dùng OR cả. Đơn giản là vì sao mà dùng OR được

Chính xác là dùng OR là không được. Ý mình muốn nói là cần sử dụng phép loại suy (tức là dùng các toán tử khác, hoặc các phép dịch, xoay, cộng trừ ....) để tìm ra kết quả cho nên lấy 1 toán tử khác để làm ví dụ. Tuy nhiên sẽ sửa lại phần này vì viết phần này không rõ.

hơn nữa cũng là vì không thấy bác nhắc đến cộng/trừ (chắc bác cũng đoán ra rằng nếu đã dùng cộng/trừ tại sao không dùng luôn XOR còn nhanh hơn gấp nhiều lần).

Nếu XOR xong, ra keystream, không biết được nó là gì thì mới thử tiếp các thể loại transposition/substitution cipher truyền thống (nhưng đối với software hiện đại thì xác suất chúng nó sử dụng mấy loại này là cực thấp).

Chính xác tới độ con mắt.

Cám ơn mọi người đã góp ý. Sẽ chỉnh lại bài viết.
Thân.

@anh TQN: Em cũng đang tìm hiểu cái DWORD đó có ý nghĩa gì. Còn CodeVeil em chưa cài IDA trong Virtual Machine nên chưa apply được symbol cho mscorjit do đó vẫn chưa biết là nó hook hàm nào. smilie

).

Rồng tiếp tục với RE để decode username và password của YM đi. Lúc trước anh có thử làm nhưng bỏ dỡ giữa chừng.

Em không hiểu ý anh chỗ này.

@kien: Lão rồng nghỉ game lâu rùi lão ui. smilie

).

Hí hí chắc lão mỏi tay nhất là khoản capture và che đi những phần nhạy cảm lolz

Quá oải luôn, 1h sáng phải bật Desktop lên chỉnh lại bài viết vì lộ ID trong bài viết. smilie

).

Bác rongchaua, ngay từ khi phát hiện ra độ dài của ciphertext = độ dài của plaintext, bác có thể kết luận ngay rằng đây là stream cipher, chứ không cần phải thử OR (AND) hay XOR, vì hiển nhiên OR (AND) operation không phải one-to-one mapping.

Giả sử kết quả tìm ra không phải là toán tử XOR mà chỉ đơn giản là mỗi bytes cộng thêm/trừ đi một số nào đó thì sẽ sao nhỉ? Ciphertext lúc đó cũng bằng Plaintext. Và mẫn là one-to-one mapping. Nhưng không là toán tử XOR hoặc đây cũng là 1 cách http://en.wikipedia.org/wiki/Caesar_cipher .
Cho nên mình có nói qua 1 ít (rất ít) trong bài viết về statistical attack. Nếu ai đó thấy thích thì sẽ tìm hiểu thêm. Với stream cipher thì plaintext = ciphertext nhưng chiều ngược lại thì không hoàn toàn là vậy.

@choc_: mình nghĩ bạn không cần thiết viết thừa thãi như vậy, phương pháp thì đã trình bày trong bài viết rồi, nhỡ người nào đó không rõ trình độ của bạn lại cho rằng bạn đọc xong bài viết rồi mới phát biểu câu này thì sao?

Thực ra cái này thì trên mạng cũng đã có nói chung chung nên về khái niệm thì nếu ai quan tâm thì cũng đã biết. Mình cũng đã tìm thử trên Google tài liệu để đọc cho lẹ nhưng không thấy có ai viết hết nên đành phải tự mò thôi.

@choc_: còn 4 bytes từ offset 4 trong Header mình vẫn chưa hiểu dùng để làm gì? Nếu bạn biết thì chia sẻ cho mọi người.

Thân.

Hôm nay ngồi tìm hiểu thử cách encode message của Yahoo Messenger và reverse giải thuật encrypt của nó. Viết lại để lưu trữ. Chia sẻ với mọi người.

http://rongchaua.net/security-mainmenu-28/18-crypto/130-yahoo-archive-decode

Thân.
rca

Vừa code xong 1 tool nhỏ để detect rootkit dạng này.

GAC Verifier
http://rongchaua.net/tools-mainmenu-36/129-gac-verifier

Nó sẽ quyét thư mục GAC và trả về trạng thái chữ ký của các assembly. Nếu assembly nào bị thay đổi sẽ có status là "Not valid". Từ đó có thể tiến hành các bước xử lý thích hợp.
Thân.

Thanx, một research khá hay, rất tiếc là tool .Net Sploit không chạy được trên máy mình để test. Cả một research quan trọng nhất chỉ mấy câu này

Trong Presentation

Another approach was taken, revealed during this research
It was found out that the signature is used just to map to the correct directory name on the GAC
the SN mechanism does not check the actual signature of a loaded DLL but just looks for a DLL inside a directory with this signature name !

Trong White Paper

Upon request for this DLL from other executables running inside the framework, the
framework will search for the required DLL based on his version and signature. The
framework will not check for the actual signature but instead will rely on the signature
mentioned in the directory file name.

Mình cũng sẽ nghiên cứu lại vấn đề này để chắc chắn và viết tool exploit riêng vì tool đi kèm không hoạt động trên máy mình rùi.