banner

[Rule] Rules  [Home] Main Forum  [Portal] Portal  
[Members] Member Listing  [Statistics] Statistics  [Search] Search  [Reading Room] Reading Room 
[Register] Register  
[Login] Loginhttp  | https  ]
 
Messages posted by: StarGhost  XML
Profile for StarGhost Messages posted by StarGhost [ number of posts not being displayed on this page: 2 ]
 
À ừ mình nhầm. Cái đó là Current IPTC Digest, còn IPTC Digest thì đi kèm trong file. Như vậy có khả năng là 2 file ảnh đó được sửa ở 2 máy khác nhau. Tuy nhiên mình không nghĩ ra tại sao Photoshop lại set giá trị đó thành 0x0.
@WinDak: IPTC digest không phải là thông tin ở trong file, mà nó được tính toán bởi exiftool và show ra cho bạn. Trong trường hợp này có nghĩa là bạn đã chạy exiftool để xem thông tin về 2 file ảnh đó trên 2 máy khác nhau, và một trong 2 máy đó không có Digest::MD5 module trong Perl, vì vậy nó cho ra toàn zeros. Còn nếu như IPTC không theo standard location thì nó sẽ thông báo "Ignored non-standard IPTC at $path". Chi tiết xem trong [ExtractPath]/Image-ExifTool-8.43/lib/Image/ExifTool/IPTC.pm:1007-1032

Code:
if ($tagTablePtr eq \%Image::ExifTool::IPTC::Main) {
# calculate MD5 if Digest::MD5 is available (for standard IPTC only)
my $path = $exifTool->MetadataPath();
if (IsStandardIPTC($path)) {
my $md5;
if (eval 'require Digest::MD5') {
if ($pos or $dirLen != length($$dataPt)) {
$md5 = Digest::MD5::md5(substr $$dataPt, $pos, $dirLen);
} else {
$md5 = Digest::MD5::md5($$dataPt);
}
} else {
# a zero digest indicates IPTC exists but we don't have Digest::MD5
$md5 = "\0" x 16;
}
$exifTool->FoundTag('CurrentIPTCDigest', $md5);
} elsif ($Image::ExifTool::MWG::strict and $$exifTool{FILE_TYPE} =~ /^(JPEG|TIFF|PSD)$/) {
# ignore non-standard IPTC while in strict MWG compatibility mode
$exifTool->Warn("Ignored non-standard IPTC at $path");
return 1;
}
# set family 1 group name if multiple IPTC directories
my $dirCount = ($exifTool->{DIR_COUNT}->{IPTC} || 0) + 1;
$exifTool->{DIR_COUNT}->{IPTC} = $dirCount;
$exifTool->{SET_GROUP1} = '+' . $dirCount if $dirCount > 1;
}
Mấy cái trong document ancestors là lấy từ Document ID mà ra, thế nên nếu giống nhau thì tức là 2 ảnh này xuất phát từ cùng một bức ảnh. Tuy nhiên điều này không có nghĩa là 2 ảnh này được sửa trên cùng một máy. Dù vậy, 2 ảnh này cùng sử dụng sRGB, và không phải là mặc định Adobe RGB của CS5, thế nên nhiều khả năng là sửa bởi cùng một người.
@pmquang: vậy cái NAT trên router của bạn hoạt động như thế nào bạn có biết không? Còn về việc nhận ICMP lỗi rồi xoá NAT entry thì bạn cần phải thử nghiệm thực tế rồi mới nên đưa ra kết luận.

Ngoài ra, bạn upload cái network dump của teamviewer lên đây thử coi.
@quanta: rất cám ơn quanta vì cái tên hole punching. Kĩ thuật này thực ra vô cùng đơn giản, mình cũng không ngờ rằng người ta có đặt tên cho nó, nên buộc phải dùng ý tưởng của port knocking để đưa ra gợi ý. smilie

@pmquang: Bạn nên kiểm tra các UDP packets gửi từ A và B đến server rồi so sánh với các UDP packets giữa A và B.

@all: mình để ý thấy trong link bạn quanta đưa có đề cập rằng kĩ thuật này không mấy hiệu quả với symmetric NATs. Các bạn nghĩ xem liệu có cách nào bypass symmetric NATs không? smilie

pmquang wrote:
Nếu không bình thường router chỉ cần drop gói tin đó đi mà không quan tâm gì cả.  

Bạn cứng nhắc chính là ở chỗ này. Bạn cho rằng router sẽ drop gói tin vì bạn nghĩ rằng nó được gửi từ ngoài Internet, theo nguyên tắc của port knocking, nhưng có nhất thiết phải vậy chăng?

pmquang wrote:

Em chưa hiểu ý anh lắm. Không phải cơ chế NAT cũng là một dạng firewall sao. Mặc định thì router sẽ đong tất cả các cổng. Khi một host trong LAN muốn ra ngoài thì phải đi ra theo NAT động. Còn một gói tin muốn đi xuyên ngược lại vào mạng LAN thì phải có một cổng external mở trên router. Nếu không thì gói tin sẽ bị drop. Nhưng vấn đề là router có hiểu các knocking của phía bên kia không. 


Bạn vẫn sử dụng khái niệm port knocking một cách quá cứng nhắc. Như mình đã đề cập ở trên, cái bạn cần sử dụng là ý tưởng chủ đạo của port knocking, tức là gửi một/vài packets có chủ đích dẫn đến việc thiết bị trung gian (ở đây là NAT) mở port(s). Câu hỏi đặt ra là ai gửi và gửi những gì, có cần thiết server trung gian nào đó ở ngoài Internet hay không, tại sao cần, và cần bao nhiêu. Ngoài ra, NAT và firewall là hai khái niệm hoàn toàn khác nhau. NAT hoạt động theo xu hướng cho phép tạo kết nối, còn firewall thì ngược lại, nó ngăn chặn kết nối.
@pmquang: mình nói port knocking chỉ là một gợi ý, chứ mình không nói là dùng nó để vượt qua NAT. Port knocking là khái niệm đối với firewall, nhưng bạn hoàn toàn có thể ứng dụng ý tưởng của nó để vượt qua NAT. Bạn hơi phức tạp hoá vấn đề. Ý tưởng của port knocking rất đơn giản: gửi một loạt packets có chủ đích đến firewall để nó mở một (vài) port(s) nào đó. Vậy nếu bây giờ là NAT thay vì firewall thì sao?
@pmquang: việc kết nối giữa 2 máy mà ở giữa là hai cái NAT không phải là không được (bao gồm cả symmetric NAT). Bạn nên tìm hiểu về port knocking.
@pmquang: như mình đã nói ở trên, muốn xem giá trị thực của ack và seq bạn xem trong TCP header, nghĩa là bạn có thể xem ở phần binary data của packet. Trong cửa sổ của Wireshark có 3 phần, 1 phần chứa danh sách packets, phần thứ hai chứa cấu trúc packet đang xem, và phần thứ 3 chứa binary representation của packet đó. Thân mến.
1 và 0 bạn thấy chỉ là relative seq hoặc relative ack do wireshark tính toán. Muốn biết giá trị thực phải xem trên TCP header. Còn tại sao một loạt các gói tin có cùng số seq hoặc ack là vì ack packets không bao giờ được acknowledged, nếu không thì sẽ tạo thành một vòng lặp vô hạn trong công tác packet acknowledgment.

Thân mến.

zjm_zjm wrote:
Ò ... buồn 1 phát smilie, nhưng mục tiêu cố gắng của mình đâu phải là được vào cái group elite smilie), chỉ tò mò trong đó có những topic hay trong đó thôi smilie


Chả có topic nào hay đâu, tò mò chi mất công. Tất cả các thảo luận/tán gẫu chính vẫn là ở các phân mục public cho toàn thể mọi người. Tài liệu thì ở trong thư viện, công cụ thì cứ lên google. Chúc bạn hết buồn.

explorer88 wrote:
connectionless: Không có một con đường định sẵn nào cả, các IP datagram sẽ được các router forward theo các tuyến khác nhau để đến đích 


@explorer88: bạn chắc hiểu sai khái niệm connection-oriented và connectionless. Connectionless tức là một bên có thể gửi một gói thông tin đến bên kia mà không cần báo trước, và cũng không cần biết bên kia có nhận được hay không. Và ngược lại thì là connection-oriented.

Còn về chuyện tại sao ở tầng IP thì là connectionless, rồi ở tầng TCP lại là connection-oriented, thì bạn cần phải xem xét về trade-off giữa efficiency và effectiveness. Cụ thể, mỗi một hoạt động trên Internet (routing, DNS, file transfer, WWW, v.v...) có thể là connectionless hoặc connection-oriented, tuỳ theo mục đích và đòi hỏi của hoạt động đó.

Ở network layer hoạt động chính là IP, nên nó bắt buộc phải là connectionless. Hoạt động nào muốn sử dụng connection-oriented thì thường phải qua TCP, nếu không muốn tự quản lý connection của chính nó.

Khái niệm physical connection và logical connection của bạn thực ra không có nhiều ý nghĩa, bạn cũng không cần phải quan tâm đến chúng.
@vitcon01: SSL là một networked cryptographic protocol. Chữ kí số là một algorithm. PKI là một system. Cả 3 thứ này kết hợp lại mới tạo ra cái gọi là dịch vụ chứng thực. Bạn cần đọc kĩ hơn về phần kĩ thuật thì mới nắm rõ được 3 khái niệm trên tương tác ra sao.
Exercise: Bạn đọc RFC 4306 (IKEv2) để biết SPI được trao đổi ra sao. Khi động đến protocols thì RFCs là nguồn tài liệu chính xác nhất và rõ ràng nhất.
@WinDak: cái đó mình cũng từng tham gia mà, cũng tương tự như HVA vậy. Còn hội của benina có các hoạt động mạnh hơn so với chỉ trao đổi thảo luận trên diễn đàn.
Cái này hay a. Cơ mà mình cứ ngỡ là ở VN đã phải có hội này từ lâu rồi chứ nhỉ. Đội hình kienmanowar, hacnho, TQN, rongchaua v.v... hoá ra lại không lập hội giống như vnsecurity à?

Cái quan trọng là benina thử đề xuất xem hội chính xác sẽ hoạt động như thế nào thì mới thu hút được thành viên. Mình cho rằng trước hết 1 trong những hoạt động hấp dẫn mà hội này có thể làm là tổ chức đào tạo trực tuyến, có bài giảng, có bài tập, bài thi, v.v... Hướng đi nữa là tổ chức challenges + awards.
Mình không rõ segfault chỗ nào vì mình ko gặp, nhưng mình cho rằng cách dùng variable "item" của bạn không chuẩn. Bạn xem lại chỗ "if (item >= MAX_NUMBER_POINTER)".

p/s: mình thấy bạn "chào hàng" trong mục xin việc nhiệt tình thế mà mấy chỗ debug đơn giản vậy ko làm được là sao? Thêm nữa, với lối coding vậy ai mà dám thuê bạn code đây?
Bạn phải đưa ví dụ lên đây là trong trường hợp input thế nào bị segfault, thì việc debug dễ hơn nhiều.
Bạn skoch300 có thể cho biết bạn làm thế nào ra được như vậy chăng?
Việc có thêm khả năng sử dụng TeX là điều đáng được hoan nghênh. Tuy nhiên, việc thêm box "Mật Mã" thì không nên, vì mặt bằng chung của HVA chưa phù hợp cho việc thảo luận về "Mật Mã", mặc dù trong diễn đàn có một số thành viên có tìm hiểu về "Mật Mã". Bản thân mình cũng chỉ là người mon men tìm hiểu về "Mật Mã" vậy.
@louisnguyen27: làm đến tiến sĩ theo mong muốn của cha mẹ thì thật là đáng nể, rất có hiếu.

panfider wrote:
đang biên dịch gcc
mình phải checksum lại source gcc 


Biên dịch gcc thì có liên quan gì đến virus trong Linux, và tại sao lại phải biên dịch gcc?
@OP: Còn mình khuyên bạn nếu đã có hứng thú đến thế thì recompile lại bash rồi debug nó cùng với cái ifconfig để xem nó làm cái gì. Còn thực sự mình cũng không tin tưởng lắm là strace với ltrace nó giúp ích nhiều cho bạn với một mớ bòng bong các "cuộc gọi".

Bạn nên dùng strace với ltrace khi mà bạn chỉ muốn biết là chương trình đã thực hiện các calls loại nào, ví dụ khi cần kiểm tra về security.

Hoặc đơn giản hơn nữa thì kiếm mấy quyển sách về linux kernel, bảo đảm trong đó có mô tả qua.
@hvthang: bạn có thể nói rõ hơn về vấn đề non-repudiation trong trường hợp WoT so sánh với PKI được không?

Mình thì mình cho rằng lí do WoT không được dùng rộng rãi như PKI, nếu chỉ tính trên phương diện security, thì chẳng có tí dính dáng gì đến vấn đề kĩ thuật hết. Quan điểm của mình là: WoT và PKI được thiết kế với 2 mục đích khác nhau, trên thực tế mỗi cái hoạt động ở một môi trường của riêng nó, nơi mà cái kia hoàn toàn không được ưa thích.

À, mà nếu mà nói về việc cái nào dùng rộng rãi hơn dựa trên số lượng certificates của mỗi bên, thì mình cũng không chắc là PKI hay WoT nhiều hơn đâu nhé.

Ngoài ra, mình cho rằng có một thứ còn yếu hơn PKI và WoT rất rất nhiều mà nó vẫn được dùng hết sức phổ biến, mà hình như chưa bao giờ bị than phiền về vấn đề security. Mình để bạn đoán thử coi nó là cái gì?
@hvthang: chính vì mrro đã đọc sách nên mới thắc mắc về các nhận định của bạn, thế nên việc bạn viện dẫn tên các tài liệu sách vở mà không đi sâu chi tiết hầu như chẳng có ý nghĩa gì. Mình cho rằng bạn đã đi lệch trọng tâm của vấn đề, bởi vì chúng ta đang bàn về độ an toàn của chữ kí số, chứ không phải là của một hệ thống PKI. Nếu nói về an toàn của PKI thì không chỉ liên quan đến chữ kí số, mà còn có rất nhiều vấn đề khác, tỉ như physical security, database security, communication security, etc.

Ngoài ra, như mrro đã nói, khi bạn đưa ra nhận định về độ an toàn, thì trước đó bạn cần thiết phải định nghĩa thế nào là an toàn, chứ không bạn cứ nói an toàn tuyệt đối, hay gần tuyệt đối gì gì đó như vậy thì chả khác gì mấy tay nhà báo.

Một điều quan trọng nữa, là mrro đang thảo luận câu hỏi tại sao, trong khi bạn toàn đưa ra các facts để trả lời câu hỏi như thế nào.
@mrro: mình chỉ xin đính chính một chút xíu trong cái formal definition của digital signature. Cái đoạn b:=Vrfy(pk, m, s) nên thay bằng b <-- Vrfy(pk, m, s), vì Vrfy() không nhất thiết phải là một deterministic function.

@all: mình nghĩ là không cần thiết phải tranh cãi nữa, vì ở đây tồn tại 2 luồng quan điểm khác nhau, gây ra bởi các thành phần đứng ở 2 góc độ khác nhau, trong 2 môi trường khác nhau, mặc dù sự hiểu biết một cách hữu dụng về chủ đề này có thể là như nhau.
Chủ đề này đáng ra phải hot, nhưng còn chưa hot vì:
- người đặt câu hỏi/thắc mắc còn chưa nêu rõ vấn đề mình cần hỏi/thắc mắc, mà chỉ nói chung chung là khó hiểu, hoặc giả đặt câu hỏi không đến đầu đến đũa.
- người đặt câu hỏi/thắc mắc chưa chứng minh được rằng mình đã tìm tòi, nghiên cứu, và gặp khó khăn trong việc hiểu các tài liệu căn bản có liên quan.

TCP có quá nhiều corner cases và unusual cases để mà có thể bao quát hết trong một chủ đề, đặc biệt nếu lại liên quan đến cả operation lẫn security.
 
Go to Page:  First Page 1 2 3 5 6 7 Page 8 Last Page

Powered by JForum - Extended by HVAOnline
 hvaonline.net  |  hvaforum.net  |  hvazone.net  |  hvanews.net  |  vnhacker.org
1999 - 2013 © v2012|0504|218|