| |
|
|
ntnguyen wrote:
Đầu tiên, bạn đã khẳng định chắc rằng "Làm thế nào để trở thành 1 siêu lập trình viên?" là 1 câu hỏi "khá trẻ trâu"?
Vậy 2000 views cho cái thread này đều toàn bộ là những "đứa", những "thứ", những "loại" hay chú ý tới mấy câu "trẻ trâu" của bạn nên mới cố gắng tiếp thu hết sao? Bao gồm cả StarGhost?
Bằng chứng ở đâu? Có người chỉ vào đọc rồi đi ra, có người đọc và tìm thấy cái gì đó, có người đọc và chẳng nhìn thấy gì, và có người chỉ biết "xem".
ntnguyen wrote:
Thứ hai, nếu đã biết rõ mình là "trái tim bên lề", là không thật sự am hiểu, là dân ngoại đạo, chân ướt chân ráo bước vào IT. Vậy tại sao còn viết cái tut này chỉ dẫn cho mấy đứa nhỏ nữa?
Hại não tụi nó à? Hay spam? Hay là viết cho vui thế thôi?
Tôi đã nói rất nhiều lần: Đó là tinh thần chia sẻ và đóng góp. Nếu bạn thấy sai ở đâu, cứ việc phản biện, chứ đừng mang những lý thuyết suông, tư tưởng cố hữu ra để phán xét. Bằng chứng là, đến cái bình luận này của tôi, bạn vẫn không thể nào trả lời được những câu hỏi tôi đã hỏi bạn.
ntnguyen wrote:
Thứ ba, bài viết lúc nào cũng sặc mùi tiền, mùi "đẳng cấp", là "thượng lưu", là "cảnh giới tối thượng" mà không biết rằng để đạt được những thứ đó cần có những bước đi đầu tiên như thế nào?
Ảo à Levis?
Bạn không thèm xem những gì tôi đã viết ở trên. Thôi thì tôi quote xuống đây cho bạn "xem" vây:
Về nhận xét của anh cho việc không đưa ra cái khái niệm về "siêu lập trình viên" hay lập trình viên "pro" là do quan điểm của em về cái khái niệm này cũng chưa thực sự rõ ràng. Bởi vì ngay từ đầu em đã nhận xét cái câu hỏi "Làm thế nào để trở thành 1 siêu lập trình viên?" là hết sức điên rồ, và em nghĩ là chưa chắc đã tồn tại 1 "siêu lập trình viên". Thế nhưng theo cách nghĩ của đa số các bạn học lập trình và các bạn làm lập trình hiện tại thì em tin là trong quá trình học tập và làm việc của họ, không dưới một lần họ đã từng ước mơ trở thành 1 "siêu lập trình viên". Có vẻ hơi xa vời và không mấy liên quan nhưng em xin được ví một "siêu lập trình viên" với một vị Phật, vị Tiên hay Bụt trong tín ngưỡng dân gian Việt Nam. Mấy vị này thì chưa có ai gặp được, nhưng đa phần người dân bình thường vẫn luôn tin vào họ và những phép màu của họ. Và họ không ngừng mơ ước "ước gì mình được trở thành Tiên, thành Phật". Thế nhưng chẳng ai có thể định nghĩa được rõ ràng hoặc trả lời được các câu hỏi như "Thực sự thì Tiên, Phật là ai?". Có lẽ Tiên, Phật chỉ là hình tượng được con người tạo nên bằng trí tưởng tượng và thực hiện hoãn mĩ hoá, để nó trở thành 1 cái tấm guơng để cho con người nhìn vào, noi theo và tự sửa mình. "Siêu lập trình viên" cũng thế. Thế nên trong bài viết em không có định nghĩa cụ thể về một "Siêu lập trình viên". Cũng như trong tất cả các giáo điều, giáo lý của các tôn giáo đều khuyên con người ta tu thân hướng thiện để mong thành "chính quả", thì bài viết này của em cũng nhằm mục đích đó, để hướng và động viên mọi người tích luỹ và trau dồi các kiến thức cần có, để khi lãnh hội đủ kiến thức rồi tự bản thân sẽ có một quan điểm riêng, đúng đắn hơn về cái gọi là "Siêu lập trình viên".
ntnguyen wrote:
Suy nghĩ về Thành Quả và Thành Công đi Levis.
KHÔNG CÓ THÀNH QUẢ SẼ KHÔNG CÓ THÀNH CÔNG.
Đừng có tối ngày ngồi đó mộng tưởng ôm đống tiền rồi đếm bằng cân ký. Thay vào đó tìm 1 cuốn HTML để mong viết được 1 web page, và lờm "lũ bạn cờ hó" của bạn đi. Nó sẽ có ích.
Tôi không hề mộng tưởng hay ảo tưởng gì cả. Tôi đến với IT bắt đầu từ niềm đam mê và tình yêu, và tôi cố gắng thu nhặt tri thức, không phải để kiếm tiền, mà để thỏa mãn tình yêu với IT của tôi. Vì vậy tôi không nghĩ đến chuyện tiền bạc gì cả, mà điều tôi quan tâm nhất là tôi có thể tiến xa đến đâu trong con đường chinh phục tri thức.
ntnguyen wrote:
"Em không biết bắt đầu từ đâu?"
Nếu đã biết chắc không trả lời được, hãy im lặng đi Levis. Còn hơn là bảo mấy đứa "Hãy làm như vầy..."
Rồi sau đó nói là: Ồ, lúc ấy tôi chỉ nêu ra ý kiến cá nhân thôi.
Tôi là dân ngoại đạo nên cũng không hiểu lắm.
Thực ra tôi có tìm hiểu chút ít và hy vọng chúng giúp ích được cho nữa đời còn lại của bạn.
Đừng bao giờ làm thế nhé Levis. Rất là ác độc đấy.
Ác độc nhất khi mình chỉ biết giữ cho riêng mình và không biết chia sẻ, không biết truyền lửa lại cho thế hệ sau. Đến đây tôi có thể khẳng định rằng: Bạn không hiểu bất cứ điều gì tôi viết. Tôi không viết để cho những người đọc bài viết này ôm ảo tưởng hay mơ mộng viển vông, mà tôi viết để giúp họ biết cách tìm và đạt được tri thức, có tri thức rồi sẽ tự mình tìm ra được con đường đi cho riêng mình, chứ không viết nhằm mục đích dạy người ta kiếm tiền kiếm bạc. Một lần nữa tôi yêu cầu bạn "đọc" chứ đừng "xem", nếu như bạn vẫn muốn tiếp tục tranh luận.
Nếu bạn vẫn nghĩ tôi đang viết bài để dạy người khác cách làm việc kiếm tiền, trở nên nổi tiếng thì xin lỗi, tôi sẽ không tranh luận thêm nữa.
|
 |
|
|
Hãy tranh luận bằng thực tế, thực nghiệm để tìm ra cái chưa phù hợp, cái thiếu sót, và đừng lôi các triết lí suông ra để bảo vệ luận điểm. Càng ngày tôi càng thấy bạn đi lệch chủ đề quá nhiều, đi từ việc nhận xét đến việc chỉ trích và miệt thị. Tôi thật sự không muốn thảo luận một chút nào, một phần do sự lệch lạc trong quan điểm phản biện của bạn, một phần là do bạn chưa trả lời thoả đáng bất cứ câu hỏi nào tôi đặt ra ở phía trên, một phần nữa là do bạn luôn muốn áp đặt quan điểm của bạn cho người khác, tôi đã nói: Suy nghĩ của tôi và của bạn khác nhau. Tôi biết, khả năng tôi có giới hạn, và tôi cố gắng truyền tải tất cả những gì mình trải nghiệm được. Tuy là dân tài chính nhưng thời gian tôi đam mê và gắn bó với cntt không phải nhiều, cũng không phải quá ít. Tôi tự học, rất là khó khăn vì không có người chỉ dạy, không qua trường lớp đào tạo chính quy, không có chương trình đào tạo rõ ràng. Vì vậy, hơn ai hết tôi hiểu được những nguyện vọng, khó khăn mà con người ta gặp phải trong quá trình tích luỹ tri thức. Có rất nhiều người đặt những câu hỏi "em không biết bắt đầu từ đâu", "em phải học gì, phải làm gì". Họ có đam mê, họ mong muốn được học hỏi nhưng họ không có điều kiện để học, giống như tôi vậy. Thế nên tôi muốn chia sẻ kinh nghiệm của tôi cho họ, không phải để đánh bóng tên tuổi, hoặc là để chứng tỏ ta đây hiểu biết.
P/s: bạn vẫn chưa "đọc", tôi nói bạn xem thảo luận giữa tôi và anh StarGhost, bạn chỉ "xem" bài của anh ấy mà không "xem" bài trả lời của tôi ở phía dưới.
Và về Debugger, bạn có hiểu chữ "P/s" ở đầu câu nói:
P/s cho phần này: có vài lần tôi dùng một vài IDE hiện đại ngày nay thấy việc debug bằng các debugger tích hợp trong IDE khá là tẻ nhạt khi đa số chỉ cho phép xem và trace theo giá trị của các biến. Tuy vẫn có thể debug kèm theo nhiều thông tin hơn, nhưng như vậy thì vẫn khá là nhạt, tôi vẫn thích dùng mấy cái "hàng nóng" như olly hay gdb hơn, có vẻ rất đã tay smilie. Có lẽ nào khi debug bằng các IDE quá nhiều nên bây giờ có nhiều người không coi trọng việc debug (thậm chí có nhiều người coi debug chỉ như một thao tác mang tính chất thủ tục) như vậy chăng?
có ý nghĩa gì hay không? Đó là một câu mở rộng, nói ra ngoài vấn đề của bài viết như một thông tin bổ sung, và mang tính chủ quan, chứ không phải là 1 phần chính thức của bài viết. Bạn có hiểu điều này không?
P/s 2: Bạn vẫn chưa trả lời bất cứ câu hỏi nào tôi đặt ra phía trên cả. Nếu thật sự có tinh thần đóng góp và muốn giữ quan điểm của mình, hãy thể hiện bằng việc trả lời những câu hỏi đó trước, ít ra cũng sẽ có vài câu liên quan đến topic này
|
|
|
|
Tôi đã đặt nghi vấn ngay từ đầu là bạn chỉ "xem" bài viết của tôi chứ bạn không "đọc" bài viết của tôi. Và đến giờ tôi có thể khẳng định điều đó là đúng. Bởi vì bạn chẳng hiểu gì về những gì tôi muốn nói cả. Các câu hỏi phía trên tôi hỏi bạn, bạn chưa trả lời được hết, hãy trả lời tất cả và trả lời tiếp những câu hỏi sau đây. Nếu không trả lời được hết, thì nên dừng tranh luận tại topic này bởi những gì tôi nghĩ và những gì bạn nghĩ nằm ở 2 nơi rất khác nhau. Và đây là một nơi để thảo luận, chứ không phải nơi để công kích cá nhân kiểu
ntnguyen wrote:
Show cái mớ kiến thức lượm lặt để lườm mây đứa nhỏ sao?
Hồi trước khác, bây giờ khác. Cái thời đại gom tất cả newbie lại chung thành "1 bọn" đã chấm dứt từ khi xuất hiện ntnguyen rồi đó bạn.
ntnguyen wrote:
Đây nữa nè chú em
Trước khi bắt đầu vào thảo luận (tranh luận), hãy biết cách để tôn trọng người khác trước.
Đây là những câu hỏi tiếp theo của tôi
ntnguyen wrote:
Trái tim bên lề thì "dẹp" ngay câu này đi nhé.
HVA cho tới thời điểm hiện tại chưa có được bao nhiêu người đủ bản lĩnh "giúp bạn định hướng con đường mình cần đi" cho tất cả mọi người đâu nhé.
HVA có luật "không chuyên nghiệp thì không được chia sẻ" từ bao giờ thế nhỉ? Và nếu có, thì nó nằm ở đâu? CẢM PHIỀN bạn đưa tôi cái link hoặc trích dẫn để tôi tham khảo. Đây là một diễn đàn, mọi người đều có quyền chia sẻ, dù ít hay nhiều, nhưng luôn xem trọng tinh thần đóng góp cho cộng đồng chứ không phải là nơi để thể hiện cái "đủ bản lĩnh" của cá nhân.
ntnguyen wrote:
Tôi copy lại đấy, còn gì chối nữa không?
Ngay từ đầu, bạn không nói là: Chỉ hỗ trợ lập trình trên nền Unix, Android, iOS... hay bất cứ cái gì mà có mã nguồn mở khác.
============>>>>>>>>>> Tôi có quyền nghĩ đến việc bạn đang hướng dẫn "sửa đổi nhân của họ Windows"
Chữ "Windows" tôi viết nó nằm ở chỗ nào trong câu trích dãn đó? Một người đạt đến trình độ System Programming/ Kernel Programming thì có cần phải chỉ tận tay, day tận mặt cho họ biết là nền tảng nào hỗ trợ kernel development, nền tảng nào không hỗ trợ (không cho phép) kernel development hay không? Ở đây bạn dùng tư tưởng của cá nhân bạn để áp đặt vào tư tưởng của người viết, rồi đánh giá đó là sai lầm. Khác gì tôi bán cho bạn 1 con dao, bạn không mang đi chặt cây mà bạn mang đi chém người, rồi quay về đổ tội cho người bán dao "tại mày bán dao nên tao mới dùng để chém người"? (sorry mọi người chỗ này hơi bạo lực tí).
ntnguyen wrote:
VẬY CHO HỎI: CÁI TÍNH NĂNG NÀO CỦA "HÀNG NÓNG" CỦA BẠN HỖ TRỢ ĐƯỢC TẬN RĂNG THEO Ý CỦA TÔI VẬY?
Bạn đưa 1 đoạn code nên không giải quyết được vấn đề gì ở đây. Bởi vì tôi đã nói từ đầu, bài viết mang tính định hướng chứ không phải mang tính phân tích kĩ thuật (là do bạn cố ý kéo ra). Mặc dù vậy, tôi muốn bạn sử dụng cái System.Diagnostics của bạn để lấy về cho tôi được list Import libraries/import functions, read debug symbols, set (remove) hardware breakpoint/memory breakpoint, disasm về ASM code + opcode, hiển thị giá trị của các Register, flags trong CPU... ?
ntnguyen wrote:
Write code không hỗ trợ user biết cách xây dựng 1 chương trình nhé. Đó là UML.
Mà bạn cũng đừng dùng StarGhost để "lòe" tôi.
Dám vỗ ngực lớn tiếng với bạn luôn là với phạm vi bài viết này, thì "đó" chỉ là một MÀU XANH
Tôi dùng anh StarGhost để "lòe" bạn? Rõ ràng bạn không hiểu ý tôi muốn nói. Tôi đã nhắc đến anh StarGhost là bởi vì tôi đã có bài trả lời cho các nhận xét của anh ấy ở phía trên để làm rõ hơn quan điểm và mục đích bài viết của tôi -> có nghĩa là đã có các bài thảo luận ở phía trên, có chúaa các thông tin, luận điểm có liên quan, và điều tôi muốn nói là bạn hãy đọc các bài trả lời đó trước khi bắt đầu viết các bình luận mới. Hỏi thật bạn 1 câu, bạn đã đọc các bài thảo luận đó chưa?
|
|
|
|
ntnguyen wrote:
Cá nhân mình cho rằng việc dấn thân vào ngành CNTT để kiếm tiền là chuyện của ";bọn trẻ". Còn theo cách nhìn của "1 siêu lập trình viên" theo ý của bạn, thì không đúng. Bước chân đầu tiên của một lập trình viên chân chính không bao giờ bắt đầu bằng tiền.
Bạn đọc lại câu này tôi đã viết:
Lúc đầu tôi vẫn cho rằng câu hỏi này thực sự rất viển vông bởi vì cái ham muốn điên rồ của cái người hỏi câu này (đã được tôi nói ở phía trên)
ntnguyen wrote:
Theo hướng này thì bạn có đứng - ngồi - nằm viết ứng dụng theo kiểu gì đi nữa thì cũng không bao giờ trở thành như tiêu đề được đâu. Bời vì theo ý đó, đẳng cấp cao nhất bạn có thể đạt được chỉ là sự đương đại, chứ không phải là công nghệ vượt bậc.
Sự đột phá trong bất cứ ngành nghề nào cũng phải từ việc chấp nhận không đi theo lối mòn, là sự khác biệt so với số đông.
Bạn lấy những công việc cần làm khi mới bắt đầu để đánh giá kết quả của cả một quá trình? Bài viết tôi chỉ viết đến đó là dừng lại?
ntnguyen wrote:
Về ý này thì mình có 1 lời khuyên là bạn nên tham khảo namespace System.Diagnostics
Nguyên văn trên MSDN đây: The System.Diagnostics namespace provides classes that allow you to interact with system processes, event logs, and performance counters.
Có cả ngăn xếp Stack và vùng Heap mà bạn cần.
Bạn đã thử debug bằng olly, gdb hay các công cụ đại loại như thế để biết chúng có những gì? Và sẽ ra sao đối với các ngôn ngữ khác .NET? (tôi không muốn so sánh mạnh yếu và tính năng của các ngôn ngữ hay các IDE, đã nói ngay từ đầu rồi và bạn vẫn mang .NET vào đây)
ntnguyen wrote:
Thứ nhất: Bạn nên tìm hiểu về nhiệm vụ và cách thức làm việc của một Project Manager để hiểu hơn về chổ này.
Thứ hai: Mình dám cá là khi Windows 7 được thiết kế xong, thì Steve Ballmer cũng không thể nói ra được chính xác là trên Windows 7 có tất cả bao nhiêu files/folers của hệ thống - thứ mà KHÔNG PHẢI kế thừa của các phiên bản đàn anh trước đó.
Nếu tính 100.000 nhân viên thiết kế cho phần nhân (Kernel), mỗi nhóm góp 1 chút, thì lượng mã sinh ra sẽ rất khủng. ==>> Không thể tính bằng sức của 1 người cho các Project lớn.
Một ý nữa là không thể có được sản phẩm phần mềm hoàn thiện nhất. Bằng chứng là mỗi sản phẩm đều có version kèm theo. Mỗi lần update thì, hoặc là up thêm tính năng, hoặc tích hợp bản vá lỗi.
Sự hoàn thiện của một sản phẩm phần mềm không đánh giá hoàn toàn bằng những nhận xét của chuyên gia. Mà còn ở người dùng cuối, hãng thứ ba, các hacker/cracker ẩn danh.
Không hiểu ý bạn chỗ này lắm, bài viết của tôi cố gắng để định hướng nhằm giúp người đọc tràu dồi kĩ năng lập trình của bản thân (đã nói trong phần trả lời anh StarGhost), chứ không hướng tới cái gì gọi là "project" cả. Sự trau chuốt phải tiến hành từ những điều nhỏ nhất là chất lượng của những dòng code mình viết ra(bài viết của tôi muốn nói đến điều này), chứ không đến từ những "big project".
ntnguyen wrote:
1. Bạn nhầm lẫn giữa việc học một ngôn ngữ lập trình và làm thế nào để xây dựng cấu trúc một chương trình. Programming và UML là khác nhau.
Không hiểu ý kiến này bạn nêu ra từ đâu, có phù hợp hay không khi đây là một bài viết mang tính định hướng?
ntnguyen wrote:
2. Bạn gộp chung kết quả của nhiều sự việc lại và gán ép sự am hiểu kiến thức cho một người. Kevin Mitnick nổi danh một thời, nhưng chưa có ai nhắc đến việc anh ấy đã từng ngồi viết dòng: MessageBox.Show("Hello World!");
Để cấu hình được một Server, không nhất định phải giỏi về các namespace trong .Net Framework.
Bạn nên đọc lại dòng này tôi đã viết:
....mà tối sẽ chỉ nêu ra hướng bạn cần đi để trở thành một "pro", theo các suy nghĩ, kinh nghiệm và quan điểm của cá nhân tôi.
Và không hiểu ví dụ bạn đưa ra có liên quan gì đến quan điểm của bạn nêu? Và xin nhắc lại, đây là một bài mang tính chất định hướng chứ không phải phân tích kĩ thuật chuyên sâu.
ntnguyen wrote:
3. System Applications là bạn viết các ứng dụng trên nền của OS. Còn Kernel programming là cái gì? Nghe đây:
KHÔNG MỘT AI CÓ THỂ ĐỌC ĐƯỢC NHỮNG DÒNG CODE CỦA NHỮNG FILES SYSTEM (THUỘC PHẦN NHÂN - KERNEL) CỦA WINDOWS, NGOẠI TRỪ MICROSOFT.
Việc cấy thêm đoạn mã vào cho System làm việc theo ý mình giống như cách mà bạn làm với họ Unix trên Windows là chuyện không tưởng.
Tôi đã nói là "kernel programming trên Windows" lúc nào vậy? Ở trong bài viết tôi có nói đến từ "trong Windows" đâu nhỉ?
ntnguyen wrote:
4. Mức độ khả thi của một chương trình được thẩm định thông qua một hoặc nhiều thành viên tạo nên chương trình đó (chủ bản quyền, có thể có hoặc không bao gồm người viết code).
Còn mức độ toàn vẹn bảo mật theo ý của bạn, là giai đoạn gia công và testing (Testers). Một trong những bước sau cùng trước khi sản phẩm hoàn thiện.
Tôi đã nói ở phía trên:
Không hiểu ý bạn chỗ này lắm, bài viết của tôi cố gắng để định hướng nhằm giúp người đọc tràu dồi kĩ năng lập trình của bản thân (đã nói trong phần trả lời anh StarGhost), chứ không hướng tới cái gì gọi là "project" cả. Sự trau chuốt phải tiến hành từ những điều nhỏ nhất là chất lượng của những dòng code mình viết ra(bài viết của tôi muốn nói đến điều này), chứ không đến từ những "big project".
ntnguyen wrote:
5. Windbg là một debugger mạnh, rất mạnh. Hoạt động trên nền Windows x86 lẫn x64. Được tích hợp trong Windows Kits. Đây là Debugger hiện đại đấy bạn.
http://hvaonline.net/hvaonline/posts/list/45816.html#281552
Tôi vẫn đang dùng Windbg song song với OllyDbg và các debugger khác trong vài năm trở lại đây. Tôi coi chúng là "hàng nóng" 
ntnguyen wrote:
6. Cách trình bày bài viết của bạn, đọc rất là nhức mắt. Excellent Programmer luôn có cách nhìn thẫm mĩ tốt cho các sản phẩm của mình.
Không biết bạn có đọc kĩ bài viết hay không, nhưng tôi đã viết ngay trên đầu bài:
...mặc dù tôi là dân tài chính chứ không phải theo công nghệ thông tin, hoàn toàn là 1 "trái tim bên lề"...
Cho nên tôi không phải là 1 Excellent programmer. Việc tôi có thể làm chỉ là làm nổi bất các phần quan trọng và đánh dấu các đề mục của từng phần. Về thẩm mĩ thì có nhiều quan điểm khác nhau lắm, tùy vào con mắt của mỗi người.
ntnguyen wrote:
Cuối cùng. Để trở thành Thần Thánh, đôi khi chỉ cần viết đúng 1 con virus. Nhưng nếu là một chuyên gia, bạn có chắc ai cũng biết đến bạn không?
Không hiểu câu này lắm? Mục đích cuối cùng chỉ là để cho mình trở nên nổi tiếng, được nhiều người biết đến? Lần thứ 3 tôi nhắc lại ý kiến của tôi:
...Không hiểu ý bạn chỗ này lắm, bài viết của tôi cố gắng để định hướng nhằm giúp người đọc tràu dồi kĩ năng lập trình của bản thân (đã nói trong phần trả lời anh StarGhost)...
Regards
|
|
|
|
9aa6 wrote:
Levis wrote:
9aa6 wrote:
Lập trình giỏi có phải là can thiệp điều chỉnh viết chương trình đc trên tất cả các máy tính đúng ko?
Như thế chưa đủ. Câu này tương đương với câu nói "Tôi biết rất nhiều ngôn ngữ -> Tôi là một lập trình viên giỏi". Việc biết nhiều ngôn ngữ hay viết được nhiều ứng dụng chạy trên nhiều hệ thống máy tính khác nhau chưa đủ để chứng tỏ bạn là một người giỏi lập trình. Cái quan trọng là bạn cần phải hiểu rõ về ngôn ngữ cũng như hệ thống bạn đang sử dụng để khai thác tối đa sức mạnh của chúng theo cách hiệu quả nhất có thể
9aa6 wrote:
Mình có 1 hệ điều hành trống ko như window chẳng hạn ko có phần mềm nào chỉ có hđh đc cài sẵn .ko có tool dev .chỉ có côg cụ soạn thảo notepad thì có thể viết chương trình cho máy tính đó ko?
Câu này làm mình liên tưởng đến mấy cái máy smartphone. Bạn thử tìm hiểu về cách viết một ứng dụng cho smartphone xem sao
viết ứng dụng cho smarphone hay window đều phải có sdk mà , tool dev soạn thoả dịch lỗi , bạn xem lại kỹ câu hỏi "Mình có 1 hệ điều hành trống ko như window chẳng hạn ko có phần mềm nào chỉ có hđh đc cài sẵn .ko có tool dev .chỉ có côg cụ soạn thảo notepad thì có thể viết chương trình cho máy tính đó ko?"
VD như 1 hệ điều hành như android chẳng hạn, đáp ứng đủ các tính chất bạn nói:
- Không giống windows
- Không có phần mềm nào chỉ có hệ điều hành được cài sẵn (lấy ví dụ như là bản được cook tối ưu đi)
- Không có tool dev (không hiểu ý bạn ở đây là tool dev được cài sẵn trong hệ điều hành hay là tool dev ở đâu nữa, chứ android thì sao mà cài eclipse hay jdk lên được, mà cái từ "dịch lỗi" mình mới nghe thấy đây là lần đầu tiên, không hiểu lắm).
- Chỉ có công cụ soạn thảo (vd ở đây là 1 cái app tạo note đi)
Vì thế cho nên mình liên tưởng đến mấy cái smartphone. Câu hỏi của bạn có vẻ khó hiểu với mình, nếu mình hiểu sai bạn có thể nói rõ hơn được không? 
|
|
|
|
9aa6 wrote:
Lập trình giỏi có phải là can thiệp điều chỉnh viết chương trình đc trên tất cả các máy tính đúng ko?
Như thế chưa đủ. Câu này tương đương với câu nói "Tôi biết rất nhiều ngôn ngữ -> Tôi là một lập trình viên giỏi". Việc biết nhiều ngôn ngữ hay viết được nhiều ứng dụng chạy trên nhiều hệ thống máy tính khác nhau chưa đủ để chứng tỏ bạn là một người giỏi lập trình. Cái quan trọng là bạn cần phải hiểu rõ về ngôn ngữ cũng như hệ thống bạn đang sử dụng để khai thác tối đa sức mạnh của chúng theo cách hiệu quả nhất có thể
9aa6 wrote:
Mình có 1 hệ điều hành trống ko như window chẳng hạn ko có phần mềm nào chỉ có hđh đc cài sẵn .ko có tool dev .chỉ có côg cụ soạn thảo notepad thì có thể viết chương trình cho máy tính đó ko?
Câu này làm mình liên tưởng đến mấy cái máy smartphone. Bạn thử tìm hiểu về cách viết một ứng dụng cho smartphone xem sao
|
|
|
|
Hi anh StarGhost,
Rất cảm ơn khi anh đã đọc và tham gia thảo luận topic này
Về nhận xét của anh cho việc không đưa ra cái khái niệm về "siêu lập trình viên" hay lập trình viên "pro" là do quan điểm của em về cái khái niệm này cũng chưa thực sự rõ ràng. Bởi vì ngay từ đầu em đã nhận xét cái câu hỏi "Làm thế nào để trở thành 1 siêu lập trình viên?" là hết sức điên rồ, và em nghĩ là chưa chắc đã tồn tại 1 "siêu lập trình viên". Thế nhưng theo cách nghĩ của đa số các bạn học lập trình và các bạn làm lập trình hiện tại thì em tin là trong quá trình học tập và làm việc của họ, không dưới một lần họ đã từng ước mơ trở thành 1 "siêu lập trình viên". Có vẻ hơi xa vời và không mấy liên quan nhưng em xin được ví một "siêu lập trình viên" với một vị Phật, vị Tiên hay Bụt trong tín ngưỡng dân gian Việt Nam. Mấy vị này thì chưa có ai gặp được, nhưng đa phần người dân bình thường vẫn luôn tin vào họ và những phép màu của họ. Và họ không ngừng mơ ước "ước gì mình được trở thành Tiên, thành Phật". Thế nhưng chẳng ai có thể định nghĩa được rõ ràng hoặc trả lời được các câu hỏi như "Thực sự thì Tiên, Phật là ai?". Có lẽ Tiên, Phật chỉ là hình tượng được con người tạo nên bằng trí tưởng tượng và thực hiện hoãn mĩ hoá, để nó trở thành 1 cái tấm guơng để cho con người nhìn vào, noi theo và tự sửa mình. "Siêu lập trình viên" cũng thế. Thế nên trong bài viết em không có định nghĩa cụ thể về một "Siêu lập trình viên". Cũng như trong tất cả các giáo điều, giáo lý của các tôn giáo đều khuyên con người ta tu thân hướng thiện để mong thành "chính quả", thì bài viết này của em cũng nhằm mục đích đó, để hướng và động viên mọi người tích luỹ và trau dồi các kiến thức cần có, để khi lãnh hội đủ kiến thức rồi tự bản thân sẽ có một quan điểm riêng, đúng đắn hơn về cái gọi là "Siêu lập trình viên".
Còn về cái ý kiến "chuơng trình hoàn thiện nhất" ở đây là do em chưa nói rõ ràng. Ý của em là hoàn thiện nhất đối với từng phần code trong chuơng trình chứ không phải là hoàn thiện tính năng trong một chuơng trình lớn. "Hoàn thiện code" có thể tạm hiểu là đáp ứng được 2 yêu cầu: hiệu năng/tốc độ và tính an toàn/bảo mật chứ chưa hẳn là xây dựng chuơng trình hoàn chỉnh với đầy đủ các tính năng
|
|
|
|
Gần đây tôi có đọc được 1 câu hỏi khá "trẻ trâu" nhưng lại rất thú vị:"Làm thế nào để trở thành 1 "siêu Lập trình viên"?". Nhiều người mới bắt đầu học về công nghệ thông tin thường hay hỏi và băn khoăn, nhằm là mơ ước biến thành 1 ông nào đó pro tầm cỡ bill gates hay đại loại thế. Nhưng này, theo quan điểm của cá nhân tôi thì Bill Gates nên được gọi là một nhà doanh nhân thành đạt hơn là một lập trình viên tầm cỡ. Những lập trình viên có thể nói là tầm cỡ thì nên nhắc đến những cái tên như Linus Torvalds hay Dennis Ritchie sẽ phù hợp hơn.
Quay trở lại với câu hỏi "Làm thế nào để trở thành 1 "siêu lập trình viên?"". Lúc đầu tôi vẫn cho rằng câu hỏi này thực sự rất viển vông bởi vì cái ham muốn điên rồ của cái người hỏi câu này (đã được tôi nói ở phía trên). Tuy nhiên tôi nghĩ lại rằng:"Ở, kể ra cũng có gì đáng để bàn ở đây đó chứ", thế nên tôi quyết định viết cái note này, không phải để chỉ bạn cách làm sao để trờ thành như Bill Gates, tiền không đếm mà toàn tính theo cân (kg), mà sẽ giúp bạn định hướng con đường mình cần đi để - cho dù không trở nên nổi tiếng đi chăng nữa - thì cũng đủ để bạn biến mình thành 1 cái gì đó "pro". Cũng nên lưu ý 1 chút nữa là trong bài viết này tôi sẽ không nói về các ngôn ngữ lập trình, bởi vì mỗi ngôn ngữ có đặc trưng và sức mạnh riêng của chúng, không có ngôn ngữ nào hoàn hảo cả, mà tối sẽ chỉ nêu ra hướng bạn cần đi để trở thành một "pro", theo các suy nghĩ, kinh nghiệm và quan điểm của cá nhân tôi (mặc dù tôi là dân tài chính chứ không phải theo công nghệ thông tin, hoàn toàn là 1 "trái tim bên lề" . Sẵn sàng chưa, hãy bắt đầu nào.
Con đường của tôi chọn là:
Programming -> Debugging -> System Programming/Kernel Programming -> Hacking and security
Tôi sẽ phân tích từng giai đoạn một ở dưới đây
1.Programming
Đã gọi là "siêu lập trình viên" rồi thì chắc chắn là phải biết lập trình chứ. Programming ở đây, bạn cần phải nắm THẬT vững một ngôn ngữ nào đó. Và hãy tiến hành code các ứng dụng, tiện ích từ nhỏ cho đến lớn, trước hết là phục vụ nhu cầu của mình đã, rồi phục vụ nhu cầu của người khác. VD như cứ đi dần từ việc viết mấy cái chương trình để lòe con gái, lòe cái lũ bạn "cờ hó" đến việc viết các ứng dụng thiết thực hơn như quản lý bán hàng, kế toán hoặc các phần mềm xử lý và mô phỏng đồ họa (cớ như photoshop, autocad hay premier thì càng tốt). Và ngoài ngôn ngữ mình thuần thục ra, hãy bỏ thêm thời gian để tìm hiểu và sử dụng một vài ngôn ngữ khác nữa, càng nhiều thì càng tốt, nhưng hay lượng sức mình kẻo bị "tẩu hỏa nhập ma". Việc lập trình này giúp cho bạn có kiến thức vững vàng về các ngôn ngữ lập trình và các thuật toán, giải thuật cũng như cách xây dựng 1 chương trình.
2.Debugging
Thực chất thì debugging là 1 phần không thể tách rời của programming, nhưng trong quan điểm của tôi thì tôi vẫn chia nó ra thành 1 phần riêng, bởi vì tính quan trọng của nó. Nhiều người (đặc biệt là các bạn mới học lập trình) hay có suy nghĩ kiểu "debug chỉ là gỡ lỗi cho chương trình thôi, mục đích cuối cùng cũng chỉ là tìm cách để bấm F9/F5 là chương trình chạy phà phà mà không có lỗi", nhưng đối với cá nhân tôi, debug còn mang theo nhiều thứ hơn là việc gỡ lỗi. Bằng việc debug, tôi nhìn thấy được máy tính đang hoạt động như thế nào với mỗi đoạn code được viết ra, điều này khiến tôi hiểu thêm rất nhiều thứ về hoạt động của máy tính. Việc tôi nhìn thấy cái cách mà chương trình gọi hàm như thế nào, push và pop các giá trị từ stack như thế nào, các registers và các flag của cpu thay đổi thế nào, các ô nhớ trong memory lưu trữ ra sao, hay chỉ đơn giản là câu lệnh assembly trông như thế nào khi chuyển từ các ngôn ngữ bậc cao sang... Tất cả chúng đều rất thú vị. Tôi vẫn debug cả tất cả các chương trình, kể cả chúng có lỗi hay không có lỗi, chỉ để quan sát những điều trên, thật sự rất hữu ích cho việc lập trình của tôi, để tôi không còn đặt những câu hỏi đại loại như "thế nào là 32 bit?/ thế nào là 64 bit?" và nhận được những câu trả lời rất chi là uyên thâm, đầy đủ đến mức hoàn hảo, mà cuối cùng vẫn chả hiểu thực sự nó là cái gì. Nói chung, việc debug giúp chúng ta có một cái nhìn thật sâu sắc và toàn diện hơn về cấu trúc máy tính, cách hoạt động của một chương trình chứ không chỉ dừng lại ở việc gỡ lỗi đơn thuần
P/s cho phần này: có vài lần tôi dùng một vài IDE hiện đại ngày nay thấy việc debug bằng các debugger tích hợp trong IDE khá là tẻ nhạt khi đa số chỉ cho phép xem và trace theo giá trị của các biến. Tuy vẫn có thể debug kèm theo nhiều thông tin hơn, nhưng như vậy thì vẫn khá là nhạt, tôi vẫn thích dùng mấy cái "hàng nóng" như olly hay gdb hơn, có vẻ rất đã tay . Có lẽ nào khi debug bằng các IDE quá nhiều nên bây giờ có nhiều người không coi trọng việc debug (thậm chí có nhiều người coi debug chỉ như một thao tác mang tính chất thủ tục) như vậy chăng?
3. System Programming / Kernel Programming
Con đường gian truân bắt đầu từ đây. Sau khi bạn đã có đủ kiến thức về hệ thống cũng như kiến thức về lập trình, thì bạn hãy bắt đầu với phần này. Có thể bạn sẽ thắc mắc "phần 1 và phần 3 này khác gì nhau?". Thế thì tôi xin giải thích 1 chút:
Như các bạn đã thấy trong phần 1 tôi khuyến khích các bạn lập trình ra các chương trình phục vụ cho công việc hàng ngày của các bạn cũng như của mọi người, cứ tạm gọi là Application programming đi, thì cái các bạn đang làm đó mới chỉ là cầu nối trung gian cho việc giao tiếp giữa máy tính và người dùng bình thường, và tìm cách khai thác máy tính như một công cụ hữu ích để phục vụ cho nhu cầu của mọi người. Còn system programming lại hoàn toàn khác, bạn cần tìm cách để "làm bạn" với máy vi tính, lắng nghe nó, hiểu nó để biết nó làm được những gì, và tiến tới điều khiển và tận dụng sức mạnh của nó một cách hoàn toàn. Nôm na lại là chủ yếu trong phần này các bạn sẽ cố gắng tìm cách để lập trình tương tác với phần cứng cũng như nhân của hệ điều hành và điều khiển các thành phần này hoạt động theo ý muốn của bạn. Ví dụ như viết một vài driver cho thiết bị ngoại vi, viết ra 1 compiler/debugger cho riêng mình, viêt và submit được một vài bản patch cho linux kernel, code trên các hệ thống nhúng,.... tiến xa hơn nữa thì tự tạo hẳn một cái hệ điều hành mới . Các công việc này rất chi là gian nan vì bên cạnh khả năng lập trình tốt và hiểu rõ cách hoạt động của máy tính cũng như hệ điều hành thì còn phải có kiến thức thật tốt về cấu trúc phần cứng (và cũng một phần, không phải là ít về điện và điện tử). Đến được mức này thì bạn cũng thuộc vào hạng "thần thánh" rồi chứ không phải bình thường nữa
4. Hacking and Security
Phần này là phần cuối, nhưng thực tế thì chỉ là phần "ăn theo" của các phân trên nhưng lại là cảnh giới tối thượng của một lập trình viên. Một lập trình viên giỏi cũng gần như có nghĩa là anh ta là 1 hacker cứng tay. Tuy nhiên, có nhiều quan điểm về hacking and security khác nhau, bởi vì các quan điểm đó nhiều khi được đặt trên các góc độ quy chiếu khác nhau cho nên không đồng nhất. Trong góc độ lập trình, tôi chỉ xem xét "hacking and security" là biểu trưng cho 2 mục đích chính, là ưu tiên hàng đầu và tối quan trọng của một lập trình viên:
- Độ hiệu quả của code và chương trình
- Độ tin cậy và an toàn của code và chươn trình
Có một câu chuyện bịa đặt trắng trợn như sau
Thời sinh viên....
Tôi có code ra một chương trình nho nhỏ, một cái chương trình chat để thi thoảng tâm sự với nhỏ bạn gái, 2 đứa thủ thỉ với nhau cho tiện lợi . Mọi chuyện diễn ra hết sức tốt đẹp, tối nào cũng thế, tin đi tin về rầm rầm, mùi mẫn muốn chết đi được . Tuy nhiên dạo gần đây nhỏ đó than phiền rằng sao máy của nhỏ dạo này cứ khi chat chit với tôi là lại chạy chậm và lag lắm. Thế là tôi nghi là chương trình chat của tôi có vấn đề. Kiểm tra lại thấy code vẫn ổn, các tính năng của chương trình vẫn hoạt động tốt, tuy nhiên xem xét kĩ hơn thì thấy chương trình chiếm quá nhiều memory cũng như CPU Usage. À, thì ra bị chậm và lag là do đây. Thế là tôi phải tìm cách chỉnh sửa lại code, để nó trở nên tối ưu hơn, khi chạy chiếm ít CPU và RAM hơn. Việc chỉnh sửa code này nhằm giúp cho chương trình hoạt động hiệu quả hơn, chính là việc tôi đang "hack" vào code để đáp ứng đúng cho nhu cầu của tôi (và tất nhiên của nhỏ bạn gái kia nữa hehe). Tôi mày mò xây dựng lại chương trình, áp dụng các thuật toán tốt hơn và nghĩ ra các thuật toán mới linh động hơn, cuối cùng đã thành công. Từ đó tôi và nhỏ lại chat chit tưng bừng.
Cái chuyện tình yêu tình báo nhiều khi cũng phải giấu kín để tránh cho thiên hạ soi mói (mà nhiều khi lũ bạn biết mình có "gấu" nó lại bắt khao thì khổ). Cả tôi và nhỏ đều dấu nhẹm đi, để chờ thời cơ rồi công khai cho bàn dân thiên hạ biết. Thế nhưng mà giờ G chưa đến mà đã bị mấy thằng bạn phát hiện ra, thế là khổ thân cái ví của tôi, đã chả có gì để mà bồi bổ, giờ lại phải khao nên chuyển sang trạng thái suy dinh dưỡng nặng. Tôi tự hỏi "tại sao chúng nó lại biết được nhỉ?". Tôi lần mò tìm hiểu, à thì ra chúng nó thấy tối suốt ngày ngồi cặm cụi gõ gõ bấm bấm, rồi thi thoảng lại ngồi dòm cái màn vi tính rồi cười tủm tỉm một mình, nên chúng nó sinh nghi, ngấm ngầm capture các packets trên mạng và túm được một mớ các gói tin của tôi gửi đi thông qua cái chương trình chat kia, ở dạng plain text. Thế nên chúng nó mới phát hiện ra. Suy ra là, code của tôi không an toàn và đã để lộ thông tin, khiến cho tôi bị thiệt hại nặng về kinh tế và nhỏ thì "xí hổ" nặng khi sau này thi thoảng chúng tôi vẫn bị lũ bạn tôi trêu đùa.
Tuy việc đã lộ nhưng tôi vẫn muốn hoàn thiện chương trình chat của mình để nó trở nên an toàn và bảo mật tốt hơn. Tôi áp dụng encrypt các tin nhắn rồi mới gửi đi, sang đến bên nhỏ bạn thì tiến hành decrypt ra, sau đó tiến hành kiểm tra lại thì thấy chỉ túm được một mớ packets chứa các tin nhắn đã được encrypt. Phù, thế là an toàn rồi.
Đó chỉ là câu chuyện để mô phỏng cho một phần vô cùng nhỏ của "hacking and security". Để làm được hacking and security toàn diện thì các bạn cần phải có kiến thức rất rộng lớn, về cả lập trình, hệ thống máy tính lẫn kiến thức về mạng cũng như phần cứng. Việc nâng cao hiệu quả và độ tin cậy của một sản phầm phần mềm cũng như phần cứng rất khó khăn và tốn nhiều thời gian, đòi hỏi nhiều kiến thức cũng như công sức bỏ ra, cần nhất là bạn cần phải hiểu nguyên lý hoạt động của các thành phần liên quan. Viết được code, run được chương trình, xây dựng 1 hệ thống hoạt động được là chưa đủ, cần phải làm sao để cho những thứ đó chạy thật "mượt", thật an toàn nữa. Mà cái công đoạn tối ưu chương trình này, không phải chỉ diễn ra một lần là xong, mà còn phải thực hiện rất rất nhiều lần. Sau mỗi lần chỉnh sửa nâng cấp, chương trình sẽ càng trở nên hoàn thiện hơn và an toàn hơn... Đó là lý do tại sao hacking and security là cảnh giới tối thượng của một lập trình viên, theo ý kiến cá nhân của tôi.
Kết bài thì đơn giản thôi, một người viết ra chương trình hoàn thiện nhất chính là lập trình viên giỏi nhất, bất kể anh ta dùng cách nào đi chăng nữa.
P/s: vì tôi là dân ngoại đạo, các kiến thức đều do gom góp tự học nên sẽ không tránh khỏi sai sót, nên rất mong được mọi người bổ sung và góp ý để hoàn thiện hơn
Regards
|
|
|
|
Con này Avast đã nhận diện là ELF-Tsunami.B-Trj
Một bài phân tích (có thể sẽ hữu ích) ở đây: http://blog.malwaremustdie.org/2013/05/story-of-unix-trojan-tsunami-ircbot-w.html
|
|
|
|
Phần 3
9. WinDbg
Thông tin và download: http://msdn.microsoft.com/en-us/windows/hardware/hh852365.aspx
WinDbg là công cụ nằm trong bộ Debugging Tools của WDK (Windows Development Kit), do Microsoft tạo ra, Đây là 1 trình debugger rất mạnh, có thể debug các ứng dụng ở user-mode lẫn kernel-mode. Nó cũng có thể debug các chương trình .NET. Tuy nhiên để sử dụng được WinDbg đòi hỏi có nhiều kinh nghiệm về Reverse Engineering cũng như programming. Công cụ này cũng không được sử dụng quá phổ biến khi dịch ngược các chương trình .NET, tôi thường thấy nó được sử dụng trong việc phân tích hoạt động của các file .NET bị obfuscated cũng như tìm hiểu cơ chế hoạt động của các trình packer/protector cho .NET. Nếu bạn đã tiến đến mức guru/expert – nôm na là “lão làng” rồi thì đây là công cụ không thể thiếu của bạn. Tôi cũng chưa sử dụng WinDbg quá nhiều cho việc debug cho nên cũng chưa thể đưa ra những nhận định cá nhân, vì vậy phần này chỉ viết để tham khảo + giới thiệu.
WinDbg
10. Nhóm các công cụ tiện ích nhỏ (Utilities)
Nhóm các công cụ tiện ích là tập hợp các chương trình nho nhỏ để giúp cho việc dịch ngược .NET trở nên dễ dàng hơn, chứ chúng không phải là các chương trình dịch ngược như các chương trình tôi đã giới thiệu ở trên. Số lượng các công cụ này (theo những gì tôi biết) không quá nhiều nhưng chúng thật sự rất hữu ích Chúng ta có thể kể đến:
- MSIL Opcode Table: Đây là 1 chương trình rất nhỏ cho ta xem các thông tin cơ bản của các mã IL. Đây có thể coi như một dạng cheatsheet, vô cùng tiện lợi cho ta tra cứu. Có rất nhiều các mã IL, mỗi mã IL lại kèm theo những thông tin quan trọng cho nên việc ghi nhớ tất cả là rất khó. Cho nên chúng ta RẤT CẦN đến công cụ này:
MSIL Opcode Table
- Dotnet Tracer: Một tiện ích nhỏ nhưng vô cùng đáng giá, theo tôi biết thì nó sẽ load chương trình .NET vào, sau đó hook Jit-compiler và sẽ đưa ra các thông tin vô cùng hữu ích, đại loại như:
o Các module được load
o Thông tin về các method sẽ được compile bởi jit
o Các exception
o Các thread sẽ được chạy
o ….
Đây gần như là 1 chương trình debug cho .NET, để cho ta biết được cớ chế hoạt động của chương trình cần phân tích. Để sử dụng hiệu quả công cụ này, bạn cần phải có kinh nghiệm nhất định về .NET và cơ chế hoạt động của .NET framework cũng như jit compiler
Dotnet Tracer
- .NET Method Parser
Đây là một công cụ nhỏ gọn giúp liệt kê, phân tích và đưa ra các thông tin về các method trong một chương trình .NET (offset, name, type, flag, size,….).
NET Methods Parser
Ngoài ra còn một công cụ khá tốt mà tôi muốn giới thiệu với các bạn, đó là 1 IDE mã nguồn mở và miễn phí tên là SharpDevelop (Thông tin và download: http://www.icsharpcode.net/opensource/sd/). Cá nhân tôi cảm thấy khó chịu khi sử dụng bộ Visual Studio của Microsoft vì nó quá nặng (so với cái máy già cỗi của tôi) và thêm nữa là các vấn đề liên quan đến bản quyền (dĩ nhiên là vẫn có bản Express miễn phí nhưng cũng vẫn nặng và thiếu nhiều tính năng so với các bản professional hay Ultimate mà M$ tạo ra). Vì vậy tôi chọn SharpDevelop để tạo các ứng dụng .NET, vừa nhanh lại vừa nhẹ., giao diện của chương trình cũng khá tiện lợi và trực quan. Bộ setup của nó chỉ vỏn vẹn có ~15mb nhưng khi cài đặt xong có thể code trong nhiều ngôn ngữ: C#,VB.NET, F# IronPython,…. Vì vậy tôi đánh giá rất cao IDE này,, rất tiện lợi khi cần code các công cụ, các tool nho nhỏ và các app demo.
(còn tiếp)
|
|
|
|
Phần 2
5. ILDASM
ILDASM là tên viết tắt của IL DisASseMbler. Đây là 1 công cụ decompile các file .NET của chính Microsoft tạo ra, nằm cùng trong bộ Visual Studio + Window SDK, có thể được gọi từ Visual Studio Command Prompt (nguồn: MSDN). Chức năng chính là dịch ngược chương trình .NET và có thể chuyển về dạng IL, sau đó save lại dưới dạng txt file. Chúng ta có thể sửa code từ file text này, và sau đó compile lại bằng một công cụ đi cùng với ILDASM là ILASM. ILDASM và ILASM (cũng nằm trong bộ Visual Studio).
Đúng như tên gọi của nó, ILDASM chỉ đơn thuần là 1 công cụ Disassemble không hơn không kém, và nhiệm vụ của nó chỉ là dịch ngược về mã IL, cho nên nó thiếu đi rất nhiều tính năng cần thiết như :code analysis, code search, multi-file disassemble,…
ILDASM
+ Điểm cộng: Nhẹ, có sắn (nếu như có cài Visual Studio và Windows SDK), hiện thị code tốt, export code khá tốt
+Điểm trừ: Quá đơn điệu, thiếu nhiều tính năng cơ bản cũng như các tính năng mở rông, nâng cao
6. ILSpy
Thông tin và download: http://ilspy.net/
ILSpy là trình decompiler/Disassembler mã nguồn mở, được tạo ra nhằm mục đích thay thế cho .NET Reflector sau khi Red-Gate mua lại .NET Reflector và biến nó thành phần mềm thương mại. ILSpy là 1 công cụ rất nhẹ, chỉ bao gồm các tính năng cơ bản đủ dùng, đã có thể thay thế một phần nào .NET Reflector. Cá nhân tôi thích nhất ở phần mềm này là sự nhanh và nhẹ của nó. Code sau khi dịch ngược khá chuẩn xác.
Tính năng:
• Assembly browsing
• IL Disassembly
• Support C# 5.0 "async"
• Decompilation to C#
o Supports lambdas and 'yield return'
o Shows XML documentation
• Decompilation to VB
• Saving of resources
• Save decompiled assembly as .csproj
• Search for types/methods/properties (substring)
• Hyperlink-based type/method/property navigation
• Base/Derived types navigation
• Navigation history
• BAML to XAML decompiler
• Save Assembly as C# Project
• Find usage of field/method
• Extensible via plugins (MEF)
• Assembly Lists
ILSpy
+ Điểm cộng: RẤT NHẸ, nhanh, đầy đủ tính năng cơ bản, mã nguồn mở, miễn phí
+Điểm trừ: Ít plugin, thiếu tính năng mở rộng nâng cao
7. Dotnet Resolver
Thông tin và download: http://dotnetresolver.eu5.org/
Đây là 1 công cụ do cộng động Reverser thiết kế ra, nhằm mục đích thay thế cho .NET Reflector và các chương trình decompile khác, Vì được xây dựng bởi các Reverser có nhiều kinh nghiệm cho nên nó đáp ứng được khá đầy đủ các tính năng cần thiết, vừa có sự trực quan và dễ sử dụng như .NET Reflector, vừa nhẹ và nhanh như ILSpy, vừa nhẹ và nhanh hơn cả ILSpy, và cũng rất mạnh, gần như SAE. Cá nhân tôi đánh giá đây là 1 công cụ rất tốt, tuy nhiên công cụ này khá mới mẻ và vẫn còn đang trong giai đoạn phát triển, và chúng ta có thể hi vọng sẽ có thêm nhiều tính năng mới trong tương lai. Phiên bản hiện tại rất ổn định và đã sẵn sang để sử dụng.
Tính năng:
- Translate to C# and Visual Basic
- Editing MSIL Instructions
- Stable Assembly Reader
- Member Analyser
- Plug-in Support
DotNet Resolver
+Điểm cộng: Nhanh, mạnh, khá đầy đủ tính năng, nhẹ, miễn phí, phát triển tốt, dễ sử dụng, khả năng mở rộng tốt
+Điểm trừ: Ít plugin
8. IDA
Thông tin và download: https://www.hex-rays.com/products/ida/
IDA thì quá nổi tiếng trong giới Reverser rồi. Đây là công cụ mạnh nhất trong việc dịch ngược và phân tích chương trình với rất nhiều plugin và các tính năng chuyên nghiệp. Thế nhưng nhà phát triển IDA tập trung chủ yêu vào việc phát triển công cụ này cho mục đích dịch ngược native PE file và các ứng dụng trên các nền tảng khác như iOS, ARM, Linux, Android,… Cho nên các tính năng cho việc dịch ngược .NET chỉ dừng lại ở mức vừa đủ, không thế so sánh với các chương trình dịch ngược tôi đã giới thiệu ở trên được. Và tôi cũng không sử dụng IDA quá nhiều cho việc dịch ngược các chương trình .NET, cho nên phần này chỉ viết cho mục đích để tham khảo là chính, không thể đánh giá cụ thể. Bởi vì chỉ dựa trên khả năng dịch ngược .NET của IDA mà đánh giá sức mạnh của chương trình này thì thật sự không chính xác chút nào.
IDA
(còn tiếp)
|
|
|
|
Phần 1
Các chương trình viết bằng .NET có cấu trúc khác với các native PE file, cho nên các công cụ debug/disassembler thong thường không thể phát huy hết sức mạnh, mà muốn dịch ngược được các chương trình .NET và phân tích cấu trúc + mã nguồn của chúng, không gì tốt hơn bằng việc sử dụng các chương trình chuyên dụng dành riêng cho .NET, tôi sẽ giới thiệu với các bạn trong bài viết này.
Tôi sẽ tạm thời phân chia thành 2 nhóm chương trình chính sau đây:
Nhóm Editor/Decompiler/Disassembler/Utilities: Nhóm này là tập hợp các công cụ giúp ta xem xét, phân tích cũng như thay đổi cấu trúc và thong số của chương trình .NET. Kèm theo đó là một vài tiện ích nho nhỏ để phục vụ cho quá trình dịch ngược chương trình được trở lên dễ dàng hơn
Nhóm Unpacker/Deobfuscator/Detector: Nhóm này tập hợp các công cụ giúp chúng ta phát hiện và loại bỏ các lớp bảo vệ của chương trình .NET. Hiện tại có rất nhiều các sản phẩm bảo vệ cho mã nguồn .NET để tránh việc dịch ngược, đọc và phân tích code cho nên nhóm công cụ này cũng khá quan trọng.
OK, bây giờ tôi sẽ liệt kê các chương trình phổ biến trong 2 nhóm trên. Bắt đầu với nhóm 1 trước.
1. CFF Explorer
Thông tin và download: http://www.ntcore.com/exsuite.php
Đây là 1 chương trình rất đa năng nằm trong bộ Explore Suite của NTCore phát triển. Mặc dù đây chỉ là dự án ngoài lề (Side-project) được viết bởi Daniel Pistelli, tuy nhiên các tính năng của nó được đánh giá rất cao và hữu ích. Chương trình là 1 PE Editor đúng nghĩa với các tính năng sau:
Process Viewer
Drivers Viewer
Windows Viewer
PE and Memory Dumper
Full support for PE32/64
Special fields description and modification (.NET supported)
PE Utilities
PE Rebuilder (with Realigner, IT Binder, Reloc Remover, Strong Name Signature Remover, Image Base Changer)
View and modification of .NET internal structures
Resource Editor (full support for Windows Vista icons)
Support in the Resource Editor for .NET resources (dumpable as well)
Hex Editor
Import Adder
PE integrity checks
Extension support
Visual Studio Extensions Wizard
Powerful scripting language
Dependency Walker
Quick Disassembler (x86, x64, MSIL)
Name Unmangler
Extension support
File Scanner
Directory Scanner
Deep Scan method
Recursive Scan method
Multiple results
Report generation
Signatures Manager
Signatures Updater
Signatures Collisions Checker
Signatures Retriever
(Vì đây đa phần là các thuật ngữ chuyên môn nên khi dịch ra tiếng Việt có thể không sát nghĩa, cho nên tôi để nguyên tiếng Anh).
Đây cũng là chương trình đầu tiên hỗ trợ việc xem và thay đổi cấu trúc, thông số của .NET PE file, có thể thực hiện ngay cả khi trong máy không cài .NET Framework. Ta cũng có thể mở rộng khả năng hoạt động của chương trình bằng cachs viết các script cho chương trình tự động chạy, đó cũng là điểm mạnh rất đáng giá. Vậy nên, nếu bạn muốn thực hiện Reverse Engineering .NET, đây là công cụ bạn cần phải có trong bộ “đồ nghề” của mình
CFF Explorer
+ Điểm cộng: Nhẹ, miễn phí, nhiều tính năng rất hữu ích, hỗ trợ hiệu quả .NET, khả năng mở rộng tốt
+ ĐIểm trừ: Không có
2. .NET Reflector
Thông tin và Download: http://www.red-gate.com/products/dotnet-development/reflector/
Nhắc đến .NET Reflector thì không phải là cái tên quá xa lạ đối với những ai đang nghiên cứu về .NET. Đây là công cụ phổ biến nhất trong việc dịch ngược .NET. Có một decompile engine chất lượng, có nhiều plugin/addin hỗ trợ, tính năng hữu ích, giao diện trực quan dễ sử dụng, có thể tích hợp vào trong Visual Studio, kèm theo đó là 1 “ông trùm” chống lung phía sau là Red-Gate, không lạ lắm khi .NET Reflector càng ngày càng trở lên mạnh mẽ và phổ biến hơn. Tính năng dịch ngược của .NET Reflector theo quan điểm cá nhân của tôi là rất tốt, có thể đưa về 90-95% code gốc, và có thể browse code không khác lắm so với việc chúng ta đọc code trong Visual Studio. Tuy nhiên tôi vẫn thích các phiên bản cũ của .NET Reflector khi Lulz Roeiier còn phát triển độc lập. Lúc đó .NET Reflector chạy rất nhẹ nhàng và chính xác, mặc dù không có nhiều tính năng hay ho như .NET Reflector hiện hành, và quan trọng nhất là nó “miễn phí”. Red-Gate đã mua lại .NET Reflector và biến nó thành một công cụ độc quyền của hang, và bán với giá cao. Tất nhiên là cracker / reverser không thích điều này, và họ đã phát triển các công cụ thay thế khác với tính năng giống .NET Reflector và chạy nhẹ nhàng hơn rất nhiều (tôi sẽ giới thiệu một vài các công cụ nổi bật khác ở phần dưới).
.NET Reflector
+ Điểm cộng: Mạnh, phổ biến, dễ sử dụng, nhiều addin, khả năng tích hợp tốt với Visual Studio, nhiều tính năng hữu ích
+ Điểm trừ: Nặng, mất phí, thiếu các tính năng chuyên dụng và nâng cao
3. Simple Assembly Explorer
Thông tin và download: https://sites.google.com/site/simpledotnet/simple-assembly-explorer
Đây là công cụ mà độ phổ biến của nó cũng ngang tầm với .NET Reflector. Thường được gọi tắt là SAE, một dự án mã nguồn mở được viết bởi Wicky Hu. Chương trình cung cấp các tính năng sau:
Assembler: call ilasm to assemble il file
Disassembler: call ildasm to disassemble assembly
Deobfuscator: de-obfuscate obfuscated assembly
Strong Name: remove strong name, sign assembly, add/remove assembly to/from GAC
PE Verify: call peverify to verify assemblies
Class Editor: browse/view assembly classes, edit method instructions
Run Method: run static methods
Profiler: Trace function calls and parameters with SimpleProfiler
Relector: plugin which call Reflector to browse selected assembly
ILMerge: plugin which call ilmerge to merge selected assemblies
Edit File: plugin which call your editor to view selected assembly
Plugin Sample: plugin sample
Copy Info: copy information of selected assemblies to clipboard
Open Folder: open container folder
Delete File: delete selected file(s)
Đây là các tính năng rất mạnh và chuyên nghiệp mà hầu như không có trong .NET Reflector. Một điểm mạnh khác của chương trình là có hỗ trợ sử dụng decompiler Engine của .NET Reflector hay ILSpy để đưa ra code dịch ngược dưới dạng các ngôn ngữ bậc cao (C#,VB.NET….) bởi vì mặc định của chương trình là dịch ngược về mã IL. Nó cũng có thể dịch ngược rất nhiều những file .NET mà .NET Reflector bó tay (ví dụ điển hình là các .NET bị obfuscated/packed)
Điểm yếu của chương trình là nó hơi khó sử dụng, và thích hợp với những người có nhiều kinh nghiệm hơn là những người mới bắt đầu. Tuy nhiên nếu bạn hiểu và nắm rõ cách sử dụng của chương trình, thì đây là một chương trình tuyệt vời nhất cho việc dịch ngược .NET
SAE
+ Điểm cộng: RẤT MẠNH, mã nguồn mở, nhẹ, miễn phí, nhiều tính năng chuyên nghiệp mà các công cụ khác không có, khả năng mở rộng và tích hợp các công cụ khác
+ Điểm trừ: Khó sử dụng, đòi hỏi có kinh nghiệm
4. Telerik JustDecompile
Thông tin và download: http://www.telerik.com/products/decompiler.aspx
JustDecomple của Telerik cũng là một công cụ chịu nhiều ảnh hưởng từ .NET Reflector, và được coi là sự thay thế tốt nhất cho .NET Reflector. Bao gồm các tính năng chính sau:
10 times faster than competitors.
Open API for everyone to create extensions.
Supports .NET 2, 3.5, 4, 4.5, 4.5.1, WinRT Metadata, C#5, APPX and WinMD.
Code becomes easily searchable with JustDecompile.
Create a Visual Studio project from a decompiled assembly.
JustDecompile integrates with JustCode and JustTrace.
Switch easily between different methods and assemblies in one JustDecompile instance.
Decompile referenced assemblies in a Visual Studio project.
Save resources from assemblies.
Bookmark usages in loaded assemblies.
Export code directly from the command prompt.
Decompile an assembly after browsing to it in Windows Explorer.
Đây là một công cụ khá tốt cho việc dịch ngược .NET, được một doanh nghiệp phát triển cho nên được đầu tư khá tốt. Nó bao gồm các tính năng cơ bản có trong .NET Reflector và có khả năng mở rộng tốt. Tuy nhiên vì mới được phát triển cho nên chưa có quá nhiều sự nổi bật và tính năng khác biệt nên vẫn phải đứng sau cái bóng quá lớn của .NET Reflector. Trong tương lai chắc chắn đây sẽ là một công cụ rất mạnh và hữu ích. Còn bây giờ, nó vẫn là một sự lựa chọn khá tốt cho việc thay thế .NET Reflector vì hai công cụ này tính năng có nhiều điểm tương đồng và rất dễ sử dụng. Một vài điểm khác đáng chú ý ở đây là hỗ trợ command line và khả năng export ra source code rất tuyệt. Về plugin thì lúc tôi sử dụng mới chỉ có 3 plugin.
JustDecompile
+ Điểm cộng: miễn phí, dễ sử dụng, nhiều tính năng hữu ích giống .NET Reflector, khả năng mở rộng tốt, khả năng decompile tốt, nhẹ, được phát triển khá tốt
+ ĐIểm trừ: ít plugin hỗ trợ, thiếu các tính năng chuyên dụng nâng cao
(Còn tiếp)
|
|
|
|
tem9x wrote:
Levis wrote:
Trong file có "em bé":
2 PE file embedded tại offset 00226000 và 00248000
Link scan virustotal của 1 trong 2 file PE được extract:
https://www.virustotal.com/en/file/057be6495f9139491bf08459d742b5935ec7f9a18f39df2085e1634d90335022/analysis/1396596245/
Thầy bạn cho mấy thứ này vào trong bài gửi cho sinh viên để làm gì nhỉ?
bác ơi bây h làm thế nào để xem đc nội dung file ạ? mà bác dậy e kiểm tra em bé gì gì vs ạ
Đây là file giả mạo PDF cho nên không xem đựoc đâu bạn. Xoá file và scan virus trong máy đi
|
|
|
|
Trong file có "em bé":
2 PE file embedded tại offset 00226000 và 00248000
Link scan virustotal của 1 trong 2 file PE được extract:
https://www.virustotal.com/en/file/057be6495f9139491bf08459d742b5935ec7f9a18f39df2085e1634d90335022/analysis/1396596245/
Thầy bạn cho mấy thứ này vào trong bài gửi cho sinh viên để làm gì nhỉ?
|
|
|
|
File của bạn mình mở bằng .NET Reflector bình thường, nếu bạn không mở được thì có thể thử với 1 vài tool khác như ILSpy, dotnetResolver, JustDecompiile hay SAE xem sao. Còn file .dat thì đựoc encrypt bằng DES
Edit: Đây có vẻ như là 1 phần mềm để thi tiếng Anh của FU, bạn muốn đọc code của nó để làm gì?
|
|
|
|
mình tìm thấy ở đây, không biết có giúp ích cho bạn được không :
http://www.c-sharpcorner.com/UploadFile/JTeeuwen/ExportManagedCodeasUnmanaged11262005051206AM/ExportManagedCodeasUnmanaged.aspx
Mình thấy có 2 cách: thay đổi CLI hoặc là build code thành COM component.
Nếu bạn biết về khái niệm managed dll và unmanaged dll thì sẽ dễ hơn nhiều
|
|
|
|
Ở đây:
http://social.msdn.microsoft.com/Forums/en-US/cadd6150-de10-47c5-bd5c-a356741c36b3/problem-with-function-pointer?forum=vcmfcatl
có nói
you cannot use GetProcAddress on a managed DLL. GetProcAddress will always return null, because no function is exported by a managed DLL.
|
|
|
|
http://www.codeproject.com/Articles/30815/An-Anti-Reverse-Engineering-Guide
|
|
|
|
Nếu account đó là quan trọng thì bạn cần chú ý đến các thông tin cần thiết cho việc xác thực "chính chủ" ngay từ khi tạo account đó. Bây giờ mất bò mới lo làm chuồng thì chịu rồi.
Mà liệu rằng có phải "bò" của bạn thật không đấy, hay là "bò" của người khác mà bạn muốn dắt về nhà mình?
|
|
|
|
|
Bạn đưa cái chuơng trình ấy lên đây xem sao
|
|
|
|
Tiện ích nhỏ do em tự tạo bằng Delphi để giúp mọi người trong việc phân tích shellcode được dễ dàng hơn. Do đang trong giai đoạn xây dựng nên có thể có lỗi. Nếu phát hiện ra lỗi thì xin mọi người thông báo cho em để em fix sớm nhất có thể. Xin cảm ơn!
Các chức năng:
- Convert Shellcode thành Opcode (nếu shellcode ở dạng hexstring)
- Save opcode thành binary file vào ổ cứng
- Disasm code dựa trên opcode đã convert được (masm syntax, sử dụng BeaEngine)
- Nếu Shellcode nhập vào có chứa các kí tự ko phải là kí tự hex, chương trình sẽ tự tìm kiếm và loại bỏ các kí tự này (chỉ lấy các kí tự hex)
Hình ảnh chương trình:
Chức năng của các button:
- "Convert": chuyển từ shellcode sang opcode và disasm
-"Clear" : xoá dữ liệu trong hộp nhập shellcode
-"Save dât to file": Lưu opcode đã convert thành file binary để lưu vào đĩa cứng
-"Copy to Clipboard": copy disasm code vào clipboard.
Download
http://uppit.com/qvh53sy5qg3j/ShellOp-Converter-0.1-beta-rept.7z
|
|
|
|
Cái này dc obfuscated bởi SmartAssembly. Dùng de4dot là cách nhanh nhất. Chỉ có thế thôi...
p/s: người ta hay gọi là deobfuscation (thay cho unobfuscated) và Decompiler( thay tho decompler)
Với lại cái link bạn đưa ko dùng dc, mình phải tìm link khác để down .
|
|
|
|
whatdie15 wrote:
tr0llz wrote:
Thôi đừng cãi nhau nữa, bạn nào muốn học viết virus/trojan vui lòng PM vào Inbox mình.
Mình sẽ mở lớp dạy các bạn từ căn bản cho đến nâng cao, từ keylogger cho đến rootkit, từ bypass AV cho đến tận dụng 0day của AV , từ lẩn tránh cho đến cách thức lây lan qua mạng, và làm cách nào để anonymous tối đa trên internet, và các phướng thức làm khó cho Reverser..... Nói chung là ok hết :p
Lưu ý: Vì mình không có thời gian đâu mà làm công tác xã hội nên ai muốn học thì chuẩn bị học phí nhé. Tuỳ theo số lượng mà mình sẽ tính toán học phí cho phù hợp.
Thân.
Bạn này sao quăng bom ghê thế nhỉ, nào lầ keylogger, rootkit,bypass.... tới chữ Reverse còn viết sai thì dạy ai. Ghét nhất câu :"Nói chung là ok hết", làm như mình là thiên "tài" không bằng.
Mình nghĩ cái chữ "Reverser" là đúng đó bạn . Reverser có thể hiểu là những ngừoi làm công việc dịch ngược (Nhưng trong từ điển chắc là không có ).
Còn các ý kiến khác của bạn, mình đồng ý cả 2 tay.
Quay lại cái chủ đề trojan này, từ trước tới giờ em mới thấy có con trojan có ích nhất là con trojan đầu tiên của nhân loại :"Ngựa gỗ thành Tơ-roa". Nó dạy cho em biết là đừng bao giờ tin tưởng vào vẻ bề ngoài của một sự vật hiện tượng nào đó
Còn hầu hết những con trojan khác, em chưa thấy có cái gì gọi là "ích lợi" cả, ít ra là trong cuộc sống của em.
|
|
|
|
nat ruou wrote:
đến nản tay conmale này , những người diệt trojan đương nhiên phải biết nó hoạt động thế nào thì mới diệt được
Điều này là tất nhiên. Nhưng ng ta dùng RCE chứ ko phải là tìm cách tạo trojan để hiểu trojan.
nat ruou wrote:
còn có trời mà biết người ta có dùng kiến thức đó đi nghịch ngợm phá hoại lung tung hay không
Nếu thế thì chúng ta nên tự quản lý lấy chính chúng ta trước khi phó mặc số phận cho trời.
nat ruou wrote:
thế nên mới nói, đạo đức, cái tâm trong mỗi con người mới là quan trọng
Đị học là đi học cả "tâm" và "tài" bạn ạ. Chứ ko phải người nào cũng tự kiếm dc cái "tâm" cho riêng mình. Cái "tâm" là quan trọng thì phải để cái "tâm" lên đầu. Bạn thử nhìn xem trong cái bài tập lớn này người ta chú ý đến bao nhiêu phần của chữ "tâm"? Con người có người này người kia, chứ ko ai giống nhau cả. Bạn không thể đảm bảo là 100% những người làm xong đề tài này không sử dụng nó vào mục đích xấu. Tại sao lại ko loại bỏ những tư tưởng xấu đó ngay từ đầu? Phòng bệnh luôn tốt hơn chữa bệnh mà
|
|
|
|
Thời gian còn nhiều, bạn cũng còn rất trẻ, vì thế tốt hơn hết là hãy tập trung vào việc học tập trước, đó là tiền đề cơ bản nhất để có thể đi xa hơn.
Sau này bạn có kiến thức, thi đỗ vào các trường đại học đúng ngành mà mình yêu thích, thì mới có môi trường thuận lợi để phát triển và thoả mãn đam mê của mình
|
|
|
|
|
Học về RE, debug virus đi bạn
|
|
|
|
một cách đơn giản như sau:
code mẫu:
var s,n: string;
i: integer;
begin
write('Nhap chuoi s: ');
readln(s);
n:='';
for i:=1 to length(s) do
begin
if (Ord(s[i])<$30) or (Ord(s[i])>39) then n:=n+s[i] else n:=n;
end;
writeln('Do dai chuoi nhap vao: ',length(s));
writeln('Chuoi moi: ',n);
readln;
end.
Dùng cách này thì có thể loại bỏ số ra khỏi chuối kí tự, và có thể giữ lại các chữ cái và cả các kí tự đặc biệt như dấu cách, hay các kí tự khác như ? . , / * ^ vân vân...
|
|
|
|
|
|
|
|
![[Rule]](/hvaonline/templates/viet/images/icon_mini_rule.gif "[Rule]"){kind=icon}
![[Home]](/hvaonline/templates/viet/images/icon_mini_groups.gif "[Home]"){kind=icon}
![[Portal]](/hvaonline/templates/viet/images/icon_mini_portal.gif "[Portal]"){kind=icon}
![[Members]](/hvaonline/templates/viet/images/icon_mini_members.gif "[Members]"){kind=icon}
![[Statistics]](/hvaonline/templates/viet/images/icon_mini_stats.gif "[Statistics]"){kind=icon}
![[Search]](/hvaonline/templates/viet/images/icon_mini_search.gif "[Search]"){kind=icon}
![[Reading Room]](/hvaonline/templates/viet/images/icon_mini_book.gif "[Reading Room]"){kind=icon}
![[Register]](/hvaonline/templates/viet/images/icon_mini_register.gif "[Register]"){kind=icon}
Register![[Login]](/hvaonline/templates/viet/images/icon_mini_login.gif "[Login]"){kind=icon}
Login [
